多语言BBD方案

Question

我正在考虑创建一个数据库的书籍（书籍由一个或两个图像以及一些文本和数字组成）。我希望以多语言（MULTI5-EUR开头）提供此数据，并且项目数量可以 27000 （ 25000 近似翻译）

阅读一点，我看到很多关于创建这个的方法的描述，我发现的最有趣的想法是：

• 一本独特的桌子书和每个可翻译文本的各种表格（文本，描述......每种语言的ID引用，例如）这使得mi书籍表非常大。

Books
ID | TITLE_ES | TITLE_EN | ..

• 一个独特的表格，包含常见数据（不可翻译）和＆＃34;元数据＆＃34;表格，与文化表的关系。 （文化表也与Genres，editions_name有关系。）

Books
-----------
ID | EDITION_ID | DATE | AUTHOR | GENRE_ID | METADATA_ID |...

Metadata
-----------
ID | TITLE | DESCRIPTION | SUMMARY | CULTURE_ID ...

Cultures
---------
ID | CULTURE

这个想法是这些书有很多属性，你可以用来搜索（作者，社论，isbn，日期，销售，......）和我希望尽可能高效地使用它。

我希望能够就这个主题展开一个有启发性的讨论，我们正在谈论大约3万个寄存器，每年增加500个aprox ..没有大量的数据，不是吗？

Answer 1

正如您在标签中提到Liferay，您已经省略了另一个选项：利用ServiceBuilder，您可以轻松地翻译单个列，只需声明它们是可翻译的。结果将以xml的形式存储在相应的数据库列中 - 这会使数据库规范化人员感到震惊。然而，这并不全是坏事：

以这种方式对存储进行数据库报告的思考通常很糟糕：报告工具不知道如何从某些XML内容中提取正确的语言。但是，处理来自外键关系的翻译键值对的经典报告也很糟糕。这些报告不易编写，维护也很差。您是否预见到您将使用经典报告工具？将此考虑在你的决定中。

你提到＆＃34;尽可能高效＆＃34;。效率如何？ 高效编写软件？ ServiceBuilder获胜。 高效维护软件？ ServiceBuilder获胜。 通过翻译名称有效过滤？非XML内容的数据库过滤机制将获胜。在全文索引中查找标题？ （您在问题中标记了lucene）：数据的存储方式并没有什么不同。

在所有这些想法之后，对于这个问题没有正确的答案，并且它很可能只会导致自以为是的讨论 - 根据此处的问题标准，它可能不适合stackoverflow。无论如何，我希望它有所帮助，但我宁愿期待这个问题因其讨论性质而被关闭。

请求以数据库为中心的意见，并且您将获得正常化。询问以软件为中心的意见，您将尝试最大化编写代码的可维护性。选择你最有可能发现自己的情况，然后选择结果。

Answer 2

不幸的是，你应该遵循normalization的规则，所以所有的决定都是由那些比stackoverflow中的所有人更聪明的人做出的。

但是，数据库的任何抽象都应该由数据库本身进行（例如使用视图）。这是抽象数据库的标准决定。

来自维基百科：

  

概念视图提供了内部和外部之间的间接层次。一方面，它提供了数据库的通用视图，独立于不同的外部视图结构，另一方面，它提取了数据存储或管理方式的详细信息（内部级别）。

实际上存在一个问题：如何在cvs / svn / git中对数据库的修改进行版本化？通常，结构更新查询存储在cvs / svn / git中的.sql文件中。