假设我们选择在数据库中进行。在关系模型中建模多语言实体是否有标准方法?
1. 一个大的翻译表
我们可以将所有翻译存储在一个表中,并使用语言中立键作为属性值。
Person (SSN, FirstName, LastName, Birthday)
Translation (key, langid, translation)
2. 每个实体一个翻译表
Person (SSN, Birthday)
PersonML (SSN, LangId, FirstName, LastName)
我更喜欢这种方法。它真的是一个1:N关系。
问题
似乎无法使用多语言列来形成主键。
假设每个人都有一个唯一的名字,那么(FirstName, LastName)可以用作主键。
人员(名字,姓氏,出生日期)
但是,考虑到多语言的情况,(名字,姓氏)无法唯一确定一个人。
显然我们不能添加LangId来形成主键。
人员(LangId,名字,姓氏,出生日期)
在这种情况下,一个人将存储在多行中,非键列将重复。
我们是否必须使用语言中立列作为主键?
当没有这样的列时,我们应该使用代理吗?
我被告知盲目使用代理是不可取的,我强烈同意。
更新 1
在这个例子中,我假设名字和姓氏需要本地化。
如果每个实体都有像 SSN 这样的属性,第二种方法更合理。
然而,如果它们包含需要本地化的列,则某些有效的主键可能会变为无效。
另一个例子
每个公司都有一个独特的名称,因此 CompanyName 可以用作主键。
Company (CompanyName, ...)
当涉及到本地化时,公司名称不能用作主键。我们必须发明一些代码来代表公司。
这是否意味着本地化不适用于关系模型?
更新2
3. 默认语言与其他语言之间的1:N关系
用户可能会将公司表视为:
Company(CompanyNameEnglish,CompanyNameFrench,CompanyNameSpanish,...)
当然,有重复的组,因此它违反了1NF。
改进后:
Company(CompanyNameEnglish,...)
CompanyNameML(CompanyNameEnglish,LangId,CompanyName)
问题是,即使用户不需要默认(英文)名称,我们也必须提供一个默认的英文名称。
一些用户可能提供英文名称,而另一些用户可能仅提供法文名称。
这个要求是否太牵强?
4. DBMS本地化支持
PerformanceDBA在他的评论中提到了这个问题。
我会进行更多的研究。