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