如果我们要开发多语言应用程序，我们是否应将翻译存储在资源文件或数据库中？
假设我们选择在数据库中执行此操作。是否有一种标准的方法来模拟关系模型中的多语言实体？
我们可以将所有翻译存储在一个表格中，并使用语言中性密钥作为属性值。
人（ SSN ，FirstName，LastName，生日）
翻译（密钥， langid ，翻译）
人（ SSN ，生日）
PersonML（ SSN ， LangId ，FirstName，LastName）
我更喜欢这种方法。这实际上是 1：N关系。
似乎多语言列不能用于形成主键 假设每个人都有一个唯一的名称，那么（FirstName，LastName）可以用作主键。
人（ FirstName ， LastName ，生日）
但是，在考虑多语言时，（FirstName，LastName）无法识别某人 显然，我们无法添加LangId来形成主键。
人（ LangId ， FirstName ， LastName ，生日）
在这种情况下，一个人将被存储在多个行中，而非键列将被复制。
我们是否必须使用语言中立列作为主键？
如果没有这样的列，我们应该使用代理吗？
我被告知不应盲目使用代理人，我非常同意。
在示例中，我假设 FirstName 和 LastName 受本地化约束。
如果每个实体总有某些属性如SSN，则第二种方法更有意义 但是，如果某些有效的主键包含需要本地化的列，则它们可能会无效。
每家公司都有一个唯一的名称，因此CompanyName可以用作主键。
公司（ CompanyName ，...）
在本地化方面，公司名称不能用作主键。我们必须发明一些代码来代表公司。
这是否意味着本地化不适合关系模型？
用户可能会将公司表视为：
公司（ CompanyNameEnglish ，CompanyNameFrench，CompanyNameSpanish，...）
当然有重复的组，所以它打破了1NF。
改进：
公司（ CompanyNameEnglish ，...）
CompanyNameML（ CompanyNameEnglish ， LangId ，CompanyName）
问题是我们必须提供默认（英文）名称，即使用户不需要 有些用户可能会提供英文名称，其他用户可能只提供法文名称 这个要求是否过于人为？
PerformanceDBA在评论中提出了这一点 我会做更多的研究。
答案 0 :(得分：1)
＆＃34;我被告知不应盲目使用代理人，我非常同意。＆＃34;
我也同意这一点，盲目地使用任何 绝不是一个明智的选择。
然而，并非每次使用代理键都是盲目完成的。 请记住，主键不是确保唯一性的唯一方法。大多数（如果不是所有）关系数据库都提供唯一约束和唯一索引，应该明智地使用它。 事实上，在翻译表中存储多语言数据时，使用代理键可能比使用自然数据更好。 read this article可以很好地比较自然和代理关键策略。
为了回答你的问题，我会为每个实体提供一个翻译表，只保留主要实体表中的实体非文本数据（例如你个人的出生日期和性别），以及将文本数据保存在翻译表中，使其主键由语言ID和实体表主键组成。
请注意，在这种情况下，实体表的主键必须是非文本的，而不是语言依赖的。
答案 1 :(得分：0)
您的问题没有实际意义：如果您决定将翻译存储在＆＃34;资源文件＆＃34;中，则该组资源文件 IS 数据库（或部分内容）。
要回答的更相关的问题是，例如：谁是翻译的所有者（即软件包的翻译不可或缺的部分 - 最终用户可以自定义它们）吗？诸如此类问题的答案将推动您的翻译是否可以作为二进制文件附带的资源文件。
我没有给出任何真正的答案，因为唯一能够了解决定性因素的人就是你。我只是指出要回答的更深层次的问题，这些问题将会明确。