如何在关系数据库中为多语言实体建模

如果我们要开发一个多语言应用程序,我们是否应该将翻译存储在资源文件数据库中

假设我们选择在数据库中完成它。 有没有一种标准的方法来模拟关系模型中的多语言实体?

1.一个大翻译表

我们可以将所有翻译存储在一张表中,并使用与语言无关的键作为属性值。

人( SSN ,名字,姓氏,生日)

翻译( keylangid ,翻译)

2.每个实体一个翻译表

人( SSN ,生日)

PersonML( SSNLangId ,FirstName,LastName)

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

问题

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

人( 名字姓氏 ,生日)

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

人( LangId名字姓氏 ,生日)

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

我们是否必须为主键使用与语言无关的列?
当没有这样的栏目时,我们是否应该使用代理
我被告知不应该盲目使用代理人,我非常同意。


更新1

在这个例子中,我假设名字和姓氏都受到本地化。

如果每个实体总是有一些像SSN这样的属性,那么第二种方法更有意义。
但是,如果某些有效的主键包含需要本地化的列,则它们可能会失效。

另一个例子

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

公司( 公司名称 ,...)

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

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


更新2

3. 1:N默认语言和其他语言之间的关系

用户可以将公司表格视为:

公司( 公司名称英文 ,公司名称法文,公司名称西班牙文,...)

当然有重复的组,所以它打破1NF。

改进:

公司( CompanyNameEnglish ,...)

CompanyNameML( 公司名称英文LangId ,公司名称)

问题是我们必须提供默认(英文)名称,即使用户不需要。
一些用户可能会提供英文名称,其他用户可能只提供法文名称。
这个要求是否太过于设计?

4. DBMS本地化支持

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


“我被告知不应该盲目使用代理,我非常同意。”
我也同意,盲目使用任何东西都不是一个明智的选择。

但是,并非每次使用代理键都是盲目完成的。 请记住,主键不是确保唯一性的唯一方法。 大多数(如果不是全部)关系数据库提供了独特的约束和独特的索引,并且应该明智地使用它。 事实上,在翻译表中存储多语言数据时,使用替代键可能会更好,然后使用自然语言键。 阅读这篇文章可以很好地比较自然和替代关键战略。

为了回答你的问题,我会为每个实体提供一个翻译表,仅保留主实体表中的实体非文本数据(例如在你的人的例子中出生日期和性别),并保留文本数据的翻译表,它的主键由语言ID和实体表主键组成。
请注意,在这种情况下,实体表的主键必须是非文本的,而不是语言依赖的。


你的问题是没有意义的:如果你决定将你的翻译存储在“资源文件”中,那么这组资源文件就是数据库(或其中的一部分)。

需要回答的问题更多,例如:谁是翻译所有者(即翻译是否是软件包的组成部分 - 最终用户是否可以自定义)? 这些问题的答案将推动您的翻译是否可以作为资源文件随二进制文件一起提供。

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

链接地址: http://www.djcxy.com/p/37445.html

上一篇: How to model multilingual entities in relational databases

下一篇: Database modeling for international and multilingual purposes