【问题标题】：How to model multilingual entities in relational databases如何在关系数据库中建模多语言实体
【发布时间】：2015-06-21 08:24:56
【问题描述】：

如果我们要开发多语言应用程序，我们应该将翻译存储在资源文件还是数据库？

假设我们选择在数据库中进行。 关系模型中是否有标准的多语言实体建模方法？

1。一张大翻译表

我们可以将所有翻译存储在一个表中，并使用语言中性键作为属性值。

人员（SSN、名字、姓氏、生日）

翻译（key、langid、翻译）

2。每个实体一个翻译表

人（SSN、生日）

PersonML（SSN、LangId、FirstName、LastName）

我更喜欢这种方法。真的是1:N的关系。

问题

似乎不能使用多语言列来形成主键。
假设每个人都有一个唯一的名字，那么 (FirstName, LastName) 可以用作主键。

人物（FirstName、LastName、生日）

但是，在考虑多语言时，(FirstName, LastName) 无法识别一个人。
显然我们不能添加 LangId 来形成主键。

人员（LangId、FirstName、LastName、生日）

在这种情况下，一个人将被存储在多行中，并且非关键列将被复制。

我们是否必须为主键使用语言中立的列？
当没有这样的列时，我们应该使用代理吗？
我被告知不应盲目使用代理，我非常同意。

更新 1

在示例中，我假设 FirstName 和 LastName 需要本地化。

如果每个实体总是有一些属性，如 SSN，则第二种方法更有意义。
但是，如果某些有效的主键包含需要本地化的列，则它们可能会变得无效。

另一个例子

每个公司都有一个唯一的名称，因此 CompanyName 可以用作主键。

公司（公司名称，...）

在本地化方面，公司名称不能用作主键。我们必须发明一些代码来代表公司。

这是否意味着本地化不适合关系模型？

更新 2

3。默认语言与其他语言的1:N关系

用户可能会将公司表视为：

公司（CompanyNameEnglish、CompanyNameFrench、CompanyNameSpanish，...）

当然有重复组，所以它打破了1NF。

改进：

公司（CompanyNameEnglish，...）

CompanyNameML（CompanyNameEnglish、LangId、CompanyName）

问题是我们必须提供默认（英文）名称，即使用户不需要它。
一些用户可能会提供英文名称，而其他用户可能只提供法文名称。
这个要求是不是太做作了？

4。 DBMS 本地化支持

PerformanceDBA 在他的评论中提到了这一点。
我会做更多的研究。

【问题讨论】：

Globalization of Database Stored Values的可能重复
从您的示例中完全不清楚您的数据模型中的什么需要翻译。相反，它看起来更像是“什么是好的主键”之类的问题。请使用关于您的数据模型和需要本地化的列的具体信息编辑您的帖子。
假设 SSN 代表社会安全号码（并且应该是唯一的），它似乎是主键的自然选择。在翻译表中只需添加语言标识符即可创建主键。
(a) 如果您想要一个无法发明代码的 RDB，则密钥必须由数据组成 (b) 本地化与 RM 无关，这是一个实现问题。获得一个 SQL 平台，现在本地化是标准的 (c) 如果您有本地化“问题”，那是因为您没有 [i] 商业服务器。无论您为 NONsql 编写的任何代码都将是不可移植的，当您获得 [i] 时，您必须替换它 (d) 将所有内容存储在数据库中 (e) 我不确定您是否真的理解我的答案，您还在问如何打破规则。
(e) LangId 是 Person 的一个属性，不一定是 Relational 键的一部分，它与 Person PK 是 1::1。现在，如果您确实没有拥有真正的 SQL 平台，当然，您可能必须在每个代码段中处理本地化，然后在整个过程中携带 LangId，当然，您可以在 PK 的一部分中进行，但如果 (SSN) 或 (LastName,FirstName) 是唯一的，则 (f) 是不正确的，那么加上 anything 也是唯一的。添加是多余的。

标签： database-design relational-database multilingual

【解决方案1】：

“我被告知不应盲目使用代理，我非常同意。”
我也同意这一点，盲目地使用任何东西绝不是明智的选择。

但是，并非每次使用代理键时都是盲目的。请记住，主键不是确保唯一性的唯一方法。大多数（如果不是全部）关系数据库都提供唯一约束和唯一索引，应该明智地使用它。事实上，在翻译表中存储多语言数据时，使用代理键可能比使用自然键更好。 read this article 可以很好地比较自然和替代关键策略。

为了回答你的问题，我会为每个实体准备一个翻译表，在主实体表中只保留实体的非文本数据（例如您的示例中的出生日期和性别），并保留文本数据在翻译表中，它的主键由语言 id 和实体表主键组成。
请注意，这种情况下实体表的主键必须是非文本的，并且不依赖于语言。

【讨论】：

主键不是确保唯一性的唯一方法。你能否澄清一下声明，也许可以举个例子。 RM 要求 Keys 由数据组成，当然这是提供 rows 唯一性的唯一方法。您可能将代理项分配为“主键”，但这不提供行的唯一性，结果是没有完整性的记录归档系统，特别是关系完整性（不同于参照完整性）。
我不会推荐 Ambler 或他的建议，它充满了错误，而且对 RM 一无所知。没有“替代或自然”的争论或辩论。他的建议的结果是无关紧要的。使用它会降低您答案的可信度。
(a) 阅读没问题，看来句子和我上次阅读时一样 (b) 你怎么想都无所谓；或者我的想法；或者，如果您同意我的观点，那么重要的是 E F Codd 博士在 关系模型 中所写的内容。这就要求 Key 必须由数据组成。如果您没有它们，那么您就没有 (i) 关系键或 (ii) 关系数据库。 (c) you 提供的链接是针对 Scott Ambler 撰写的页面的。他以散布“非规范化以提高性能”的神话而闻名，几十年来，然后转向规范化，敏捷，并且无法
...说明他的变化。该页面充满了错误、半真半假和虚假陈述。安布勒以对他所假设的一切的肤浅理解而闻名。福勒也是一样。 (d) 代理与自然是不是非此即彼的命题。阅读 surrogate-key wiki，它对了一半，右半部分证明了这一点。（e）您的陈述与数据库一起工作”，与您的其他陈述一起，意味着它们不是关系数据库。因此您不会知道您缺少什么，所以您对它的看法是......
我已经在我的cmets中回答了dzhu的问题。 Srrogates开一个新问题re surrogates，贴出“优点”和缺点，我来回答一下。

【解决方案2】：

您的问题没有实际意义：如果您决定将翻译存储在“资源文件”中，那么该资源文件集是数据库（或其中的一部分） .

要回答的更相关的问题是，例如：谁是翻译的所有者（即翻译是否是软件包的组成部分 - 最终用户可以自定义它们）？诸如此类问题的答案将决定您的翻译是否可以作为二进制文件附带的资源文件。

我没有给出任何真正的答案，因为唯一能知道决定性因素的人就是你。我只是指出需要回答的更深层次的问题，这将使其清楚。

【讨论】：

我承认这个问题没有实际意义。关于那组资源文件是数据库的要点。我也对使用配置文件或在数据库中存储配置感到困惑。从广义上讲，文件是数据库。鉴于关系数据库提供访问路径独立，我更喜欢数据库方法。在我正在开发的产品中，有数百个配置文件。和他们一起工作很痛苦。
我知道这种感觉。但是 SQL 是如此的残缺，以至于使用由“真正的”DBMS 管理的数据库通常也不是一件容易的事。
@dzhu。需要明确的是，RDBMS 不提供访问路径独立性或RDB，这是您在通过关系模型进行教育后实现的东西>，然后您使用 RDBMS 来实现该方法。 SQL 没有“瘫痪”。当然，如果你实现一个非 RDB，一个 Record Filing System，当然导航是残废的，但那不是 SQL。此外，有些人就是不知道如何使用它。