这个问题是关于一个比这些旧问题中已经解决的问题更复杂的问题，所有这些都是彼此重复的：
多语言数据库结构建议（2011年6月）
保存多语言数据的最佳数据库结构是什么？(2010 年 2 月)
多语言数据库设计的最佳实践是什么？（2009 年 5 月）
多语言数据库的架构（2008 年 11 月）
支持多语言用户界面的最流行的数据库方案似乎是将所有语言的所有翻译文本放在一个包含 3 列的表中：文本 ID、语言代码和文本本身。文本 id 和语言代码共同构成了主键。
这一切都很好，但现在考虑一个复杂的问题：假设文本需要可搜索。例如，假设这是一个多语言电子商店。这意味着对于输入到数据库中的每个产品类别，店主都会以支持的 N 种语言中的每一种输入产品类别的名称，然后购物者就可以通过名称搜索产品类别，用他们自己的语言。
有一个问题：Collation。
不同的语言有不同的整理顺序，适用于一种语言的整理顺序不适用于另一种语言。因此，如果所有语言的所有文本都在一个列中，那么它们将具有什么样的整理顺序？我们将如何查询数据库以查找特定文本的文本 ID？虽然在 Web 产品中搜索准确性和性能可能不是非常重要，但为了本次讨论的目的，让我们假设它们确实很重要。
大多数数据库管理员都熟悉“数据库的整理”意义上的整理概念。幸运的是，这只是默认排序规则，如果不存在其他排序规则信息，则使用默认排序规则，但也存在其他可以指定排序规则的地方：
SQL CREATE INDEX 命令支持归类规范。（虽然有传言说 Microsoft SQL Server 不支持它；有人知道吗？）
SQL SELECT 语句也支持排序规则，但在这种情况下，排序规则规范作为一个函数工作，导致索引扫描而不是索引查找，如果我们想要性能，这可能是不允许的。（再说一次，如果这是我们所能拥有的最好的，那可能总比没有好。）
我还听说在 Microsoft SQL Server 上，您可以拥有非持久化的计算列，您可以在这些列上指定排序规则并创建过滤索引，尽管我以前从未听说过，如果它是 Microsoft-SQL-Server-only功能，那么我宁愿不要使用它，无论它多么酷和经过深思熟虑。
那么，鉴于所有这些，如果目标是一个可更新和可搜索的多语言数据库，我们如何构建我们的数据库，以及我们如何执行我们的查询？
这个问题的灵感来自于此处发生的讨论：如果某些数据少于 4000 个字符，nvarchar(max) 如何将数据存储在数据库中会很快吗？