java - 多语言BBD方案

Question

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

读了一点，我看到很多关于创建它的方法的不一致，我发现的最有趣的想法是:

• 一个独特的表格 books 和每个可翻译文本的各种表格(文本、描述.. 每种语言的 ID 引用，示例)这使得 mi books 表格非常大。

Books
ID | TITLE_ES | TITLE_EN | ..

• 一个包含通用数据(不可翻译)和“元数据”表的唯一表，与文化表有关系。 (Culture 表也会与 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 个。数据量不大，不是吗？

Answer 1

当您在标签中提到 Liferay 时，您忽略了另一个选项:利用 ServiceBuilder，您只需声明可翻译即可轻松翻译各个列。结果将作为 xml 存储在相应的数据库列中——这让数据库规范化人员感到不寒而栗。然而，这也不全是坏事:

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

您提到“尽可能高效”。什么是效率？ 高效地编写软件？ ServiceBuilder 获胜。 高效地维护软件？ ServiceBuilder 获胜。 通过翻译后的名字过滤效率高吗？非 XML 内容的数据库过滤机制将胜出。在全文索引中查找标题？ (您在问题中标记了 lucene):数据的存储方式没有区别。

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

征求以数据库为中心的意见，您会得到规范化。询问以软件为中心的意见，您将尝试最大限度地提高编写代码的可维护性。选择您发现自己最有可能遇到的情况并接受结果。