sql-server - 本地化 SQL Server (2005/2008) 数据库的最佳实践

Question

问题

我确信你们中的许多人都面临过将数据库后端本地化到应用程序的挑战。如果您还没有这样做，那么我会非常有信心地说，您将来必须这样做的可能性非常大。我说的是为您的数据库实体存储文本的多种翻译(对于货币等也可以这样说)。

例如，经典的“类别”表可能具有应全局化的“名称”和“描述”列。一种方法是为每个实体创建一个“文本”表，然后进行联接以根据提供的语言检索值。

这会给您留下许多“文本”表，每个表对应您想要本地化的每个实体，并添加一个 TextType 来区分它可能存储的各种文本。

我很好奇是否有任何记录在案的最佳实践/设计模式来将这种支持实现到 SQL Server 2005/2008 数据库中(我正在具体介绍 RDBMS，因为它可能包含受支持的关键字和这有助于实现)？

对 XML 方法的思考

我一直在考虑的一个想法(尽管到目前为止只是在我的脑海中)是利用 SQL Server 2005 中引入的 XML 数据类型。这个想法是创建支持 XML 数据类型本地化的列(并绑定(bind)其架构)。 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

您将收到包含所有本地化文本的产品，这意味着您必须在客户端进行提取。这里最大的问题显然是每个查询必须返回的额外数据量，好处是更干净的设计，没有查找表、连接等。

顺便说一句，无论我在设计中最终使用什么方法，我仍然会使用 Linq To SQL(.NET 平台)来查询数据库(XML 方法应该是一个问题，因为它会返回一个 XElement，这可能是解释客户端)

因此，我们将非常感谢有关数据库本地化设计模式的建议，以及可能对 XML 思想的评论。

Answer 1

我认为您可以坚持使用 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;

请注意，与单独的表解决方案相比，此解决方案是一种优雅但效率较低的解决方案。对于某些应用程序来说这可能没问题。