Saya pikir pertanyaan seperti yang dinyatakan (pada 2015-04-20, "Yang mana [...]") bukan apa yang dimaksud, mengingat bahwa jawaban yang diterima berbicara tentang penyandian daripada pemeriksaan. Biarkan saya menjawab pertanyaan yang disebutkan daripada yang dimaksudkan, hanya karena saya pikir itu menarik :-)
Wikipedia mengatakan "Collation adalah kumpulan informasi tertulis menjadi urutan standar". Dalam komputasi, collation telah mengambil arti "spesifikasi pesanan semacam itu". Dengan kata lain, collation adalah (atau menyiratkan) definisi fungsi perbandingan tiga arah.
Saya pikir jawaban singkatnya adalah "pasti mungkin". Setidaknya saya menyadari shenanigans berikut:
#!/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.strxfrmadalah fungsi yang Returns a string that behaves for cmp locale-aware, yaitu, mengkodekan string sedemikian rupa sehingga perbandingan leksikografi standar byte demi byte terhadap string lain yang disandikan akan menghasilkan hasil yang sama dengan membandingkan string sesuai dengan fungsi pengumpulan yang ditentukan oleh lokal.
Beberapa pengamatan: di da_DK.utf8, string ouüödiurutkan. Di de_DE.utf8, string oöuüdiurutkan. Perhatikan bahwa len(long_form) == 38dan 38> 13. (Panjangnya juga 38 in de_DE.utf8.)
Jika database Anda memiliki indeks pada beberapa bidang string, disusun menurut da_DK.utf8, itu mungkin secara internal melakukan sesuatu seperti strxfrmuntuk memiliki perbandingan sederhana. (Di sisi lain, disk lambat. Mungkin lebih cepat untuk mengindeks berdasarkan representasi yang lebih kompak, jika biaya perbandingan per karakter lebih tinggi daripada mengimbangi dengan membandingkan lebih sedikit karakter.)
Anda bertanya "Apakah sebuah collation memiliki pengaruh terhadap kecepatan query?", Yang saya yakin jawabannya adalah ya: collation "C" (alias "POSIX") hanya membandingkan nilai-nilai titik kode unicode, sedangkan Denmark ( da_DK.utf8) dan bahasa Jerman ( de_DE.utf8) melakukan sesuatu yang lebih rumit. Ini akan memiliki beberapa dampak pada kecepatan query, walaupun aku curiga itu tidak akan perlu dicemaskan.
"Apakah ukuran meja berubah tergantung pada susunannya?" - Saya dapat membayangkan memiliki indeks menurut satu pemeriksaan dan indeks yang berbeda sesuai dengan pemeriksaan yang lain, atau hanya satu dari dua indeks tersebut, dengan beberapa strxfrmtransformasi seperti diterapkan. Dalam skenario hipotetis itu, jika ada dua pemeriksaan dengan karakteristik ukuran yang berbeda, jawabannya adalah ya.
"Yang mana yang merupakan susunan yang direkomendasikan?" - Itu tergantung pada mengapa Anda perlu menyortir string. Jika hanya memiliki beberapa cara kanonik memesan string, saya mungkin akan pergi dengan "C". Jika itu untuk menyajikan data kepada pengguna dalam urutan diurutkan sesuai dengan harapan manusia, dan harapan itu dibentuk oleh budaya mereka, dan Anda ingin database (dan bukan lapisan lain) untuk melakukan penyortiran, mungkin Anda harus membangun satu indeks per collation , yaitu setidaknya satu menurut da_DK.utf8untuk Denmark dan satu menurut de_DE.utf8untuk Jerman. Saya pikir ini mungkin menjadi cukup besar cukup cepat.
Semua ini sangat tergantung pada cara kerja database Anda; Saya pikir itu melampaui SQL "standar" (lol!). Seperti biasa, lihat dokumentasi untuk sistem basis data spesifik Anda.