sql-server – 本地化SQL Server(2005/2008)数据库的最佳做法

我相信你们中有许多人面临着将数据库后端本地化到应用程序的挑战.如果你没有,那么我会很自信地说,你今后必须这样做的可能性是相当大的.我正在谈论你的数据库实体存储多个文本翻译(和货币等同一点).

例如,经典的“类别”表可能具有应该被全球化的名称和描述列.一种方式是为每个实体确定一个“文本”表,然后根据所提供的语言进行加入以检索值.

这会留下许多“文本”表,一个用于您要本地化的每个实体,另外添加一个TextType以区分它可能存储的各种文本.

如果在SQL Server 2005/2008 datebase中实现这种支持有任何,记录在案的最佳实践/设计模式,我很好奇(我正在关注RDBMS,因为它可能包含支持的关键字,这有助于与实施)？

关于XML方法的思考

我一直在追求的一个想法(尽管到目前为止只有在我的头脑中)是利用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思想的评论将会非常受欢迎.

解决方法

<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;

请注意,该解决方案将是比单独的表格更优雅但效率更低的解决方案.某些应用程序可能是可以的.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!