必须有更好的方法来执行本地化的数据库字段

Question

到目前为止,已经有几个问题,他们都得到了相同的答案:一个用于语言中性数据的表,1-*到一个带有翻译的表和一个索引语言ID字段.

这有几个问题:

1. 两倍的CRUD.
2. 如果你想要一个体面友好的Web UI,需要Ajax CRUD.
3. 验证的两倍以上 - 您需要确保关系为1-*而不是0-*.
4. 不符合语言之间的整理差异.
5. 查询需要连接.
6. 如果你想要多种语言的slu ,,哦,男孩.

许多数据库人员已经研究过各种理论和实践问题,但令人惊讶的是很少有人在这方面工作.

我认为我们最终需要的是:

• 一种字段类型,它将存储多个版本的字符串
• 每个此类字段的多个索引,每种语言或变体一个,可选择指定正确的归类模式
• 这个疯狂的东西的标准ORM对象
• UI元素

矫枉过正？当然,也许,但整个问题都是真正的噩梦.这并不是一个不常见的场景.

我们必须设法说服服务器供应商来解决这个问题.

编辑:顺便说一句,这是我第一次使用社区维基; 希望我做对了.

编辑2:关于我的措辞的一些东西似乎让人们认为我正在攻击DBMS的概念.我不是; 我只是说内置的本地化支持是一项非常需要的功能.

我可能不应该提到表现; 在大多数情况下,它当然完全可以忽略不计.我关注的焦点在于这确实扼杀了生产力.

我举一个例子.假设我有一个非常简单的表,一个非常简单的商店:

Products (id, price, description, name, slug)

在EF/MVC中,我将它放在ORM设计器中,可能将其封装在存储库中,构建一个Products控制器,并为索引,细节,创建,更新,编辑和删除操作.要识别任何项目中的产品,我只需要做一个WHERE(slug = @slug).我为创建/编辑操作创建了一个视图模型,设计了表单控件,并将其直接连接到存储库.做完了.要访问产品的详细信息,用户可以访问/products/details/product-slug.

但是,由于网站的其余部分是双语的,我决定相应地更改产品表.

Products (id, price)
ProductsText (productId, language, description, name, slug)

嘿,那不是那么糟糕.是的,还没有.然后你编写你的关系和你的约束,然后你写你在视图模型中写出你的所有属性,然后你为ProductsText数据创建一个完整的CRUD控制器或使用jQuery/Ajax添加创建/更新/编辑按钮在您的Products控制器上,然后添加验证逻辑以确保用户至少输入主要语言,然后当您想要读取最终用户页面的数据时,您编写另一个查询以连接ProductsText.slug和ProductsText.语言与产品...我可能错过了一些东西,但你明白了.

一旦涉及到本地化,程序的复杂性就会随着样板代码而爆炸.

当然,我不认为问题可以完全解决,而且显然也是一个UI问题,因为它是一个数据库问题.但是,为了使这一切变得更容易,我们可以做很多事情."多字符串"字段类型可能是一个非常好的开始.

编辑3:有没有人听说过SQL Server建模服务？它有一些本地化工具,可以朝着正确的方向迈出一步.仍然是CTP.

-- Simulate the French locale with the SET LANGUAGE statement.
SET LANGUAGE French
select Id, CountryName, 
   [System.Globalization].[SessionsString](CountryName, 1) as CountryNameString
from [Location].[CountriesTable]

Answer 1

什么是本地化数据库字段？

通常在我们工作的应用程序中,UI是本地化的.这是使用数据库完成的,我们将所有翻译(可能还有主要短语)放在表中,其中locale-code和phraseid是主键.这是相当简单的,需要一组可重复使用的存储过程并具有良好的性能,并且使用方法已被充分理解.我们经常允许动态翻译,以便应用程序界面包含一个翻译功能,可以进行更正,其他用户可以看到它们 - 丰富的表单应用程序或Web表单应用程序(取决于缓存 - 这是UI本地化的另一个关键功能) )

至于查询需要连接 - 这只是规范化关系数据库中的生活事实,而且性能通常通过良好的规范化设计和正确的索引进行管理.

在其他"数据"中,除了在应用程序要求的指导下,本地化没有多大意义.例如,即使您可能在多个国家/地区提供产品,SKU和分销商也可能不同.这种级别的本地化是非常特定于应用程序的,我们经常把它作为一个单独的数据库来处理,并且确实没有任何东西将这些单独的国家数据库捆绑在一起 - 尽管在其他国家可能有相同的产品,但许多产品都没有.

如果您在世界各地销售相同的产品,那么您会陷入一种多语言CMS的原始场景.这需要除低级数据库之外的重要工作.例如,如果某人更正了默认的产品说明,那么翻译需要更正的翻译人员的标记是什么？这些问题非常重要.虽然我可以看到数据库供应商可以在哪些方面协助功能,但这些是应用程序需求和设计的固有困难,并不一定是数据库可以添加将普遍解决的功能.

整理问题确实有点尴尬.通常,数据存储在nvarchar中,并且在编写存储过程时,您不会知道要检索的排序规则,因为区域设置将是一个参数.这只会影响检索到的需要按内容排序的集合,通常不是自然键,当然也不是按键检索 - 这不是一个大问题,而是一个没有动态SQL就无法轻松处理的集合(使用表格中的首选排序规则进行转换)根据传入的位置,如果混合来自不同语言环境的数据,则必须首先确定是否要按语言环境排序,然后可能难以选择可能在同一结果集中的所有语言环境中正常工作的排序规则).您可能希望使用具有如此多种数据的Windows排序规则.

与ORM类似,我们通常将locale/phraseid的复合唯一键视为检索对象的关键(我们通常还有一个代理身份主键) - 我知道传统的ORM不一定喜欢这种从无意义的检索中脱离代理关键.