题
我相信你们中有许多人面临着将数据库后端本地化到应用程序的挑战.如果你没有,那么我会很自信地说,你今后必须这样做的可能性是相当大的.我正在谈论你的数据库实体存储多个文本翻译(和货币等同一点).
例如,经典的“类别”表可能具有应该被全球化的名称和描述列.一种方式是为每个实体确定一个“文本”表,然后根据所提供的语言进行加入以检索值.
这会留下许多“文本”表,一个用于您要本地化的每个实体,另外添加一个TextType以区分它可能存储的各种文本.
如果在sql Server 2005/2008 datebase中实现这种支持有任何,记录在案的最佳实践/设计模式,我很好奇(我正在关注RDBMS,因为它可能包含支持的关键字,这有助于与实施)？
我一直在追求的一个想法(尽管到目前为止只有在我的头脑中)是利用sql Server 2005中引入的XML数据类型.这个想法是使得应该支持本地化的列,XML数据类型(并将模式绑定到它) ). XML将包含本地化的字符串以及与之相关的语言代码/文化.
沿线的东西
Product ID (int,identity) Name (XML ...) Description (XML ...)
那么你会有这样的东西作为XML
<localization> <text culture="sv-SE">Detta är ett namn</text> <text culture="en-EN">This is a name</text> </localization>
你可以做(这不是生产代码,所以我将使用*)
SELECT * From Product Where Product.ID = 10
而且您将收到所有本地化文本的产品,这意味着您必须在客户端进行提取.这里最大的问题显然是您在每个查询上返回的额外数据量,其优点将是一个更清洁的设计,无需查找表,连接等.
Btw,我最终在我的设计中使用什么方法我仍然会使用Linq To sql(.NET Platform)查询数据库(XML方法应该是一个问题,因为它会返回一个XElement,可以解释为client-侧)
解决方法
我认为你可以坚持使用XML来实现更清洁的设计.我会进一步利用xml：lang属性,这个
is designed for this usage：
<l10n> <text xml:lang="sv-SE">Detta är ett namn</text> <text xml:lang="en-EN">This is a name</text> </l10n>
一步一步,您可以通过a XPath query(如评论中的建议)在查询中选择本地化的资源,以避免任何客户端处理.这会给出这样的东西(未经测试)：
SELECT Name.value('(l10n/text[lang()="en"])[1]','NVARCHAR(MAX)')
FROM Product
WHERE Product.ID=10;
