如果我不回击，我可能必须使用XML在我的数据库中存储一些i18n-ed数据。这不是我的选择，但它符合我必须遵循的规范。举例来说，我们可以在“国家/地区”列中进行以下操作：
<lang='fr'>Etats-Unis</lang>
<lang='en'>United States</lang>
这适用于数据库中的许多列。
我认为这根本不是一个好主意。我倾向于认为数据库中的单元格应该代表单个数据（更好地用于查找），并且数据库应该具有最大的两个维度而不是3个或更多（每个维度需要更多一个请求/ a这里的维度将等于XML属性的数量。）
我的想法是为所有翻译提供一个单独的表格，其中包含以下列：ID /语言/翻译。但是，我应该承认，我真的不确定在数据库中以各种语言存储数据的最佳方式是什么......
感谢您的建议：）
答案 0 :(得分：1)
同意你的思考愿景。
在之前的项目中，我们做了同样的事情（在DB中存储了I18N值），以及传统的I18N（解决方案中的资源文件）。
原因是需要翻译的特殊动态数据（非静态字符串）。我们有运动 - 比如“足球”，需要翻译成他们特定语言的描述。
为此，我们有一个简单的查找表，其中包含列（LCID - int, SportID - int, Description - nvarchar(256)）。
存储过程/函数将语言环境接受为整数（例如西班牙语 - 3082），然后SQL将根据语言环境返回适当的区分文化描述。这样，Web服务器代码就不会在幕后知道这一点。
所以你可能有以下几行：
Lcid SportID Description
3081 1 Soccer
3082 1 Futbol
然后，您只需在SQL中加入此表以方便I18N。
此方法的一个小缺点是，您的SQL SP将需要LCID作为Web服务器代码中的参数。
通过Excel工作表批量导入更新/导入了体育，这就是我们在数据库中需要I18N的原因。
这是我能够设想基于数据库的I18N出现的唯一方法。
答案 1 :(得分：0)
虽然XML可能不是存储它的最佳类型 - 尽管依赖于DBMS支持，它可能不像它最初看起来那样糟糕 - 翻译作为数据类型而不是规范化的概念已经存在一些优点。
My original thoughts on the topic are here，在我的同事决定在现实世界中使用它们之后，我仍然支持它们，尽管我可能会尝试编写更有效的实现。
基本上，如果你认为翻译的字符串是单个“事实”的“表示”，那么规范化就不再是工作的正确工具。相反，您可以将“已翻译的字符串”视为原子类型，以及获取正确（或最佳可用）翻译，添加新翻译等操作。
什么是“原子”的概念在哲学上是一个棘手的问题。我在博客文章中谈到单个字符串是否是“原子” - 它可以被解组成单个字符，你甚至可能想知道第一个字符是什么，但是在你正在建模的领域，通常被认为是代表性的细节，整个字符串是一个原子。不太常见，PostgreSQL包含一个“点”类型，它基本上只是两个数字的数组，但允许直接表达“包含”和“在...之上”等操作。