多语言 BBD 方案答案

【问题标题】：Multilanguage BBD Scheme多语言 BBD 方案
【发布时间】：2015-05-31 07:51:04
【问题描述】：

我正在考虑创建一个书籍数据库（书籍由一两张图片和一些文字和数字组成）。我想让这些数据以多语言提供（MULTI5-EUR 从一开始），项目的数量可能是 27000（25000 大约翻译了）

读了一点，我看到很多关于创建这个的方法的不和谐，我发现的最有趣的想法是：

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

Books
ID | TITLE_ES | TITLE_EN | ..

一个包含通用数据（不可翻译）和“元数据”表的唯一表，与一个与文化表的关系。（Culture 表也会与 Genres、versions_name.. 有关系。）

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

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

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

我们的想法是，这些书籍有很多属性可供您搜索（作者、社论、isbn、日期、销售……），我希望尽可能高效地进行搜索。

我希望就这个话题开始一个有启发性的讨论，我们正在谈论大约 30k 的寄存器，并且每年大约从 500 个增长。没有大量的数据，不是吗？

【问题讨论】：

标签： java database postgresql lucene liferay

【解决方案1】：

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

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

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

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

询问以数据库为中心的意见，你会得到规范化。询问以软件为中心的意见，您将尝试最大限度地提高书面代码的可维护性。选择你发现自己最有可能遇到的情况，然后按照结果去做。

【讨论】：

【解决方案2】：

不幸的是，您应该遵守 normalization 的规则，所以所有决定都是由比我们在 stackoverflow 中更聪明的人做出的。

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

来自维基百科：

概念视图在内部和外部之间提供了一定程度的间接性。一方面，它提供数据库的通用视图，独立于不同的外部视图结构，另一方面，它抽象出数据如何存储或管理的细节（内部级别）。

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

【讨论】：