Eu acho que a pergunta como declarada (em 20/04/2015, "Que agrupamento [...]") não é o que se entende, uma vez que a resposta aceita fala sobre codificação e não sobre agrupamento. Deixe-me responder à pergunta declarada, e não à pretendida, apenas porque acho interessante :-)
A Wikipedia diz que "agrupamento é a reunião de informações escritas em um pedido padrão". Na computação, o agrupamento assumiu o significado de "uma especificação dessa ordem". Em outras palavras, um agrupamento é (ou implica) uma definição de uma função de comparação de três vias.
Eu acho que a resposta curta é "definitivamente talvez". Pelo menos, estou ciente das seguintes travessuras:
#!/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
é uma função que Returns a string that behaves for cmp locale-aware
, ou seja, codifica uma sequência de caracteres para que uma comparação lexicográfica padrão de byte a byte com outra sequência codificada de maneira semelhante produza o mesmo resultado que a comparação de sequências de acordo com a função de intercalação especificada pelo código do idioma.
Algumas observações: em da_DK.utf8
, a string ouüö
é classificada. Em de_DE.utf8
, a sequência oöuü
é classificada. Observe que len(long_form) == 38
e 38> 13. (O comprimento também é de 38 pol de_DE.utf8
.)
Se o seu banco de dados tiver um índice em algum campo de seqüência de caracteres, agrupado de acordo com da_DK.utf8
, ele pode estar fazendo algo parecido internamente strxfrm
para fazer uma comparação simples. (Por outro lado, os discos são lentos. Pode ser mais rápido indexar com base em uma representação mais compacta, se um custo maior de comparação por caractere for mais do que compensado pela comparação de menos caracteres.)
Você pergunta "Um agrupamento tem alguma influência sobre a velocidade de uma consulta?", Ao qual tenho certeza de que a resposta é sim: o agrupamento "C" (também conhecido como "POSIX") apenas compara valores de pontos de código unicode, enquanto o dinamarquês ( da_DK.utf8
) e de_DE.utf8
locais da Alemanha ( ) fazem algo mais complicado. Isso terá algum impacto na velocidade da consulta, embora eu suspeite que não valha a pena se preocupar.
"O tamanho de uma tabela muda dependendo do agrupamento?" - Eu posso imaginar ter um índice de acordo com um agrupamento e um índice diferente de acordo com outro agrupamento, ou apenas um desses dois índices, com alguma strxfrm
transformação semelhante aplicada. Nesse cenário hipotético, se houver dois agrupamentos com características de tamanho diferentes, a resposta é sim.
"qual seria o agrupamento recomendado?" - Isso depende do motivo pelo qual você precisa classificar as strings. Se é apenas para ter uma maneira canônica de ordenar seqüências de caracteres, eu provavelmente usaria "C". Se é para apresentar dados aos usuários em ordem classificada de acordo com as expectativas do ser humano, e essas expectativas são moldadas por sua cultura, e você deseja que o banco de dados (e não outra camada) faça a classificação, talvez você deva criar um índice por agrupamento , ou seja, pelo menos um de acordo com da_DK.utf8
os dinamarqueses e outro de acordo com de_DE.utf8
os alemães. Eu acho que isso pode ficar bem grande rapidamente, no entanto.
Tudo isso depende muito do funcionamento interno do seu banco de dados; Eu acho que vai muito além do SQL "padronizado" (lol!). Como sempre, consulte a documentação para seu sistema de banco de dados específico.