Qual agrupamento devo escolher para um site multilíngue?

De um modo geral, uma das variantes Unicode é provavelmente a melhor para amplo suporte a idiomas - UTF-8 usará menos memória por ponto de código e, portanto, terá uma pequena vantagem em qualquer troca de tempo/espaço que você precise fazer; no entanto, acho que existem alguns dos idiomas/scripts mais esotéricos que o UTF-8 não pode representar (mas não tenho 100% de certeza disso, não fiz um estudo exaustivo sobre o assunto).

Este artigo da Wikipedia pode ser esclarecedor sobre as desvantagens/vantagens de cada um.

Acredito que você deva usar um agrupamento Unicode que não diferencie acentos e maiúsculas de minúsculas. Leia os artigos do MSDN Selecionando Collation e Usando SQL Collations e todos os artigos vinculados.

Acho que a pergunta declarada (em 20/04/2015, "Qual agrupamento [...]") não é o que se quer dizer, visto que a resposta aceita fala sobre codificação em vez de agrupamento. Deixe-me responder à pergunta formulada em vez da pretendida, só porque acho interessante :-)

A Wikipedia diz que "agrupamento é a montagem de informações escritas em uma ordem padrão". Na computação, o agrupamento assumiu o significado de "uma especificação de tal ordem". Em outras palavras, um agrupamento é (ou implica) uma definição de uma função de comparação de três vias.

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 string de forma que uma comparação lexicográfica padrão byte a byte com outra string codificada de forma semelhante produzirá o mesmo resultado que comparar strings de acordo com a função de collation especificada pelo locale.

Algumas observações: em da_DK.utf8, a string ouüöestá ordenada. Em de_DE.utf8, a string oöuüé classificada. Observe que len(long_form) == 38e 38 > 13. (O comprimento também é 38 pol de_DE.utf8.)

Se seu banco de dados possui um índice em algum campo de string, agrupado de acordo com da_DK.utf8, ele pode estar internamente fazendo algo como strxfrmpara ter 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 de comparação por caractere mais alto for mais do que compensado comparando menos caracteres.)

Você pergunta "Um agrupamento tem alguma influência sobre a velocidade de uma consulta?", para o qual tenho certeza de que a resposta é sim: o agrupamento "C" (também conhecido como "POSIX") apenas compara valores de ponto de código unicode, enquanto o dinamarquês ( da_DK.utf8) e os locais alemães ( de_DE.utf8) fazem algo mais complicado. Isso terá algum impacto na velocidade da consulta, embora eu suspeite que não valha a pena se preocupar com isso.

"O tamanho de uma tabela muda dependendo do agrupamento?" — 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 strxfrmtransformação semelhante a 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 de por que você precisa classificar strings. Se for apenas para ter uma maneira canônica de ordenar strings, provavelmente irei com "C". Se for para apresentar dados aos usuários em ordem de classificação 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 alguma 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.utf8os dinamarqueses e um de acordo com de_DE.utf8os alemães. Eu acho que isso pode ficar bastante grande rapidamente, no entanto.

Tudo isso depende muito do funcionamento interno do seu banco de dados; Acho que vai muito além do SQL "padronizado" (lol!). Como sempre, consulte a documentação do seu sistema de banco de dados específico.