主页 / dba / 问题 / 255
Accepted
BrunoLM
Asked: 2011-01-05 22:31:44 +0800 CST

我应该为多语言网站选择哪种排序规则？

  • 772

排序规则对查询速度有影响吗？表的大小是否会根据排序规则而改变？

如果我想建立一个必须支持所有可能语言的网站（例如谷歌），推荐的排序规则是什么？

我需要存储字符，例如日本語，我在网站上的搜索必须返回something输入sóméthíng，它也必须不区分大小写。

我怎么知道哪个是最好的选择？哪种排序规则更适合这种情况？

sql-server performance

3 个回答

  1. Best Answer

    一般来说，Unicode 变体之一可能最适合广泛的语言支持 - UTF-8 将在每个代码点使用更少的内存，因此在您发现自己需要进行的任何时间/空间权衡中都会有轻微的优势；但是，我认为有一些更深奥的语言/脚本是 UTF-8 无法表示的（但我不能 100% 确定这一点，我还没有对此事进行详尽的研究）。

    这篇维基百科文章可能对每个人的缺点/优点有所启发。

    • 16

  2. 我相信您应该使用不区分重音和大小写的 Unicode 排序规则。请阅读 MSDN 文章Selecting Collat​​ion和Using sql collat​​ions以及所有链接的文章。

    • 8

  3. 我认为所陈述的问题（在 2015-04-20，“Which collat​​ion [...]”）不是什么意思，因为接受的答案是关于编码而不是整理。让我回答所陈述的问题而不是预期的问题，只是因为我认为这很有趣:-)

    维基百科说“整理是将书面信息组装成标准顺序”。在计算中，collat​​ion 具有“这种顺序的规范”的含义。换句话说，排序规则是（或暗示）三向比较函数的定义。

    我认为简短的回答是“绝对可能”。至少我知道以下恶作剧：

    #!/usr/bin/python
name = u"Jonas K\xf6lker" # \xf6 is o-umlaut
enc = name.encode('utf-8')
assert len(name) == 12  # \xf6 is one character
assert len(enc) == 13   # but two bytes in utf-8

import locale
locale.setlocale(locale.LC_COLLATE, "da_DK.utf8") # works on my machine
long_form = locale.strxfrm(enc)
assert len(long_form) == 38

    locale.strxfrm是一个函数Returns a string that behaves for cmp locale-aware，也就是说，它对字符串进行编码，以便与另一个类似编码的字符串的逐字节标准字典比较将产生与根据语言环境指定的排序函数比较字符串相同的结果。

    一些观察：在 中da_DK.utf8，字符串ouüö已排序。在de_DE.utf8中，字符串oöuü被排序。注意len(long_form) == 38和 38 > 13。（长度也是 38 英寸de_DE.utf8。）

    如果您的数据库在某个字符串字段上有索引，根据 整理da_DK.utf8，它可能在内部执行类似strxfrm的操作以便进行简单比较。（另一方面，磁盘很慢。如果更高的每个字符的比较成本超过了通过比较更少的字符来抵消，那么基于更紧凑的表示进行索引可能会更快。）

    你问“排序规则对查询速度有影响吗？”，我很确定答案是肯定的：“C”（又名“POSIX”）排序规则只比较 unicode 代码点值，而丹麦语（da_DK.utf8) 和德语 ( de_DE.utf8) 语言环境做一些更棘手的事情。这将对查询速度产生一些影响，尽管我怀疑它不值得担心。

    “表格的大小会根据排序规则而变化吗？” — 我可以想象根据一个排序规则创建一个索引，根据另一个排序规则创建一个不同的索引，或者只是这两个索引中的一个，并strxfrm应用了一些类似的转换。在那个假设的场景中，如果有两个具有不同大小特征的排序规则，答案是肯定的。

    “推荐的排序规则是什么？” — 这取决于您为什么需要对字符串进行排序。如果只是为了有一些规范的字符串排序方式，我可能会选择“C”。如果要根据人类的期望以排序顺序向用户呈现数据，并且这些期望是由他们的文化塑造的，并且您希望数据库（而不是其他层）进行排序，也许您应该为每个排序规则建立一个索引，即至少一个根据da_DK.utf8丹麦人和一个根据de_DE.utf8德国人。不过，我认为这可能会很快变得相当大。

    所有这些都高度依赖于数据库的内部工作；我认为它远远超出了“标准化”（大声笑！）SQL。与往常一样，请查阅特定数据库系统的文档。

    • 8

相关问题