我正在考虑创建一个书籍的数据库(书籍由一个或两个图像以及一些文本和数字组成)。我想以多语言提供此数据(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 个。数据量不大，不是吗？
最佳答案
当您在标签中提到 Liferay 时，您忽略了另一个选项:利用 ServiceBuilder，您只需声明可翻译即可轻松翻译各个列。结果将作为 xml 存储在相应的数据库列中——这让数据库规范化人员感到不寒而栗。然而，这也不全是坏事:
以这种方式存储数据库报告通常很糟糕:报告工具不知道如何从某些 XML 内容中提取正确的语言。然而，处理来自外键关系的翻译键值对的经典报告也很糟糕。这些报告不容易编写，而且维护起来也很糟糕。您是否预见到您将使用经典的报告工具？将此纳入您的决定。
您提到“尽可能高效”。什么是效率？ 高效地编写软件？ ServiceBuilder 获胜。 高效地维护软件？ ServiceBuilder 获胜。 通过翻译后的名字过滤效率高吗？非 XML 内容的数据库过滤机制将胜出。在全文索引中查找标题？ (您在问题中标记了 lucene):数据的存储方式没有区别。
在所有这些想法之后，这个问题没有正确的答案，它很可能只会引起自以为是的讨论——根据此处的问题标准，它可能不适合 stackoverflow。无论如何，我希望它能有所帮助，但由于其讨论性质，我宁愿希望问题被关闭。
征求以数据库为中心的意见，您会得到规范化。询问以软件为中心的意见，您将尝试最大限度地提高编写代码的可维护性。选择您发现自己最有可能遇到的情况并接受结果。
关于java - 多语言BBD方案，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30555092/