Penso che la domanda come affermata (il 20-04-2015, "Quale fascicolazione [...]") non è ciò che si intende, dato che la risposta accettata parla di codifica piuttosto che di fascicolazione. Consentitemi di rispondere alla domanda dichiarata anziché a quella prevista, solo perché penso che sia interessante :-)
Wikipedia dice "La raccolta è l'assemblaggio di informazioni scritte in un ordine standard". Nell'informatica, le regole di confronto hanno assunto il significato di "una specifica di tale ordine". In altre parole, un confronto è (o implica) una definizione di una funzione di confronto a tre vie.
Penso che la risposta breve sia "sicuramente forse". Almeno sono a conoscenza dei seguenti shenanigans:
#!/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è una funzione che Returns a string that behaves for cmp locale-aware, cioè, codifica una stringa in modo tale che un confronto lessicografico standard byte per byte con un'altra stringa codificata in modo simile produrrà lo stesso risultato del confronto delle stringhe in base alla funzione di confronto specificata dalla locale.
Alcune osservazioni: in da_DK.utf8, la stringa ouüöviene ordinata. In de_DE.utf8, la stringa oöuüviene ordinata. Si noti che len(long_form) == 38e 38> 13. (La lunghezza è anche 38 pollici de_DE.utf8)
Se il tuo database ha un indice su un campo stringa, fascicolato in base da_DK.utf8, potrebbe essere internamente fare qualcosa di simile strxfrmper avere un semplice confronto. (D'altra parte, i dischi sono lenti. Potrebbe essere più veloce indicizzare in base a una rappresentazione più compatta, se un costo di confronto per carattere più elevato è più che compensato confrontando meno caratteri.)
Ti chiedi "Le regole di confronto influiscono sulla velocità di una query?", A cui sono abbastanza sicuro che la risposta è sì: le regole di confronto "C" (aka "POSIX") confrontano solo i valori dei punti di codice unicode, mentre il danese ( da_DK.utf8) e le de_DE.utf8lingue tedesche ( ) fanno qualcosa di più complicato. Ciò avrà un certo impatto sulla velocità delle query, anche se sospetto che non valga la pena preoccuparsene.
"Le dimensioni di una tabella cambiano a seconda delle regole di confronto?" - Posso immaginare di avere un indice secondo una collazione e un indice diverso secondo un'altra collazione, o solo uno di questi due indici, con una strxfrmtrasformazione simile a quella applicata. In quello scenario ipotetico, se ci sono due regole di confronto con caratteristiche di dimensioni diverse, la risposta è sì.
"quale sarebbe la raccolta consigliata?" - Dipende dal motivo per cui dovresti ordinare le stringhe. Se è solo per avere un modo canonico di ordinare le stringhe, probabilmente andrei con "C". Se si tratta di presentare i dati agli utenti in ordine ordinato in base alle aspettative dell'essere umano e tali aspettative sono modellate dalla loro cultura e si desidera che il database (e non un altro livello) esegua l'ordinamento, forse è necessario creare un indice per fascicolazione , cioè almeno uno secondo da_DK.utf8per i danesi e uno secondo de_DE.utf8per i tedeschi. Penso che questo potrebbe diventare abbastanza grande abbastanza rapidamente, però.
Tutto ciò dipende fortemente dal funzionamento interno del database; Penso che vada ben oltre l'SQL "standardizzato" (lol!). Come sempre, consultare la documentazione per il proprio sistema di database specifico.