这有几个问题：
>两倍CRUD.
>需要Ajax CRUD,如果你想要一个非常友好的网页界面.
>验证的两倍以上 – 您需要确保该关系是1- *而不是0- *.
不符合语言之间的整理差异.
>查询需要连接.
>如果你想要多种语言的s,哦,男孩.
很多数据库人员都在处理各种理论和实践问题,但令人惊讶的是,很少有人在这方面工作.
我想我们最终需要的是：
>一个字段类型,将存储多个版本的字符串
>每个这样的字段的多个索引,每个语言或变体一个,具有指定正确的排序规则模式的选项
>这个疯狂的事情的标准ORM对象
> UI元素
矫枉过正？当然可能,但整个问题是一个真正的噩梦,因为它是.这不是一个不常见的情况.
我们必须试图说服服务器厂商来处理这个问题.
编辑：顺便说一句,这是我第一次使用社区wiki;希望我做得对.
编辑2：关于我的措辞似乎使人们认为我正在攻击DBMS的概念.我不是;我只是说内置的本地化支持是一个非常需要的功能.
我可能不应该提及表演;大部分时间当然完全可以忽略.我关心的焦点在于这个事实真的扼杀了生产力.
我将举一个例子.假设我有一个非常简单的桌子,一个非常平凡的商店：
Products (id,price,description,name,slug)
在EF / MVC中,我将其放在ORM设计器中,或者将其封装在存储库中,构建产品控制器,并为索引,详细信息,创建,更新,编辑和删除操作.要确定任何项目中的产品,我只需要做一个WHERE(slug = @slug).我将为创建/编辑动作创建一个视图模型,设计表单控件,并将其直接连接到存储库.完成并完成要访问产品的详细信息,用户将转到/ products / details / product-slug.
但是,由于网站的其余部分是双语的,所以我决定相应地更改产品表.
Products (id,price) ProductsText (productId,language,slug)
嘿,那没那么糟是的,还没有然后你写下你的关系和约束,然后你写出你在视图模型中写出所有的属性,然后为ProductsText数据创建一个完整的CRUD控制器,或者使用jQuery / Ajax来添加创建/更新/编辑按钮在您的产品控制器上,然后添加验证逻辑,以确保用户至少输入主要语言,然后当您想要读取最终用户页面的数据时,您写入另一个查询以加入ProductsText.slug和ProductsText.语言与产品…我可能错过了一些东西,但你得到的想法.
一旦您有本地化,程序的复杂性就会随着样板代码爆炸.
当然,我并不期望这个问题得到彻底的解决,而且这显然是一个UI问题,因为它是一个数据库问题.但是,只有这么多,可以做到这一点更容易. “多段”字段类型可能是一个很好的开始.
编辑3：任何人听说过sql Server建模服务？它有some localization tools在它可能是一个正确的方向的一步.仍然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]
解决方法
通常在我们工作的应用程序中,UI是本地化的.这是使用数据库完成的,我们把所有的翻译(和潜在的主词组)放在表中,其中包含一个区域设置代码,而短语是谓词是主键.这是相当简单的,需要一个可重复使用的存储过程,并具有良好的性能,并且使用情况被很好地理解.我们经常允许翻译,以便应用界面包括一个翻译功能,可以进行更正,其他用户可以看到他们的实时 – 丰富的表单应用程序或Web表单应用程序(取决于缓存 – 这是UI本地化的另一个关键特征)
就需要连接的查询而言 – 这只是一个在规范化关系数据库中的生命的事实,而且性能通常由良好的归一化设计和适当的索引进行管理.
在其他“数据”中,除了应用要求的指导之外,本地化没有任何意义.例如,即使您可以在多个国家/地区提供产品,SKU和经销商可能会有所不同.这个本地化水平是非常具体的应用,我们经常把它作为一个单独的数据库处理,并没有什么可以将这些个别的国家数据库绑在一起 – 许多产品都不可用,尽管在其他国家可能有相同的产品.
如果您在世界各地销售相同的产品,那么您可以在一种多语言CMS中进入原始场景.除了低级数据库之外,这还需要很大的工作.例如,如果有人更正了默认的产品描述,翻译者需要更正哪些标记翻译？这些问题是不平凡的.尽管我可以看到数据库供应商可以协助功能的位置,但这些是应用程序需求和设计的固有困难,而不一定是数据库可以添加将被普遍解决的功能.
整理问题的确有点尴尬.通常,数据存储在nvarchar中,您不会知道在编写存储过程时想要检索的排序规则,因为语言环境将是一个参数.这只会影响需要由内容排序的收集,而不是通常是自然的密钥,而不是通过密钥来检索 – 这不是一个大问题,而是一个不能轻易处理的动态sql(使用表中的首选排序规则)取决于传入的位置,如果混合来自不同语言环境的数据,则必须先确定是否要按区域设置排序,然后选择可能在同一结果集中的所有语言环境中正常工作的排序规则).您可能想要使用Windows归类与各种各样的数据.
与ORM类似,我们通常将locale / phraseid的复合唯一键视为检索对象的关键(我们通常还具有代理标识主键) – 我知道传统的ORM并不一定像这样,代理关键
