Edit: het bovenstaande zal een default collation zijn, voor als een database/tabel/kolom collation niet gedefinieerd is en/of je geen expliciete COLLATE operatie doet waarbij je voorschrijft hoe je dan wel tekst vergelijkt/sorteert. Tenzij je met hele specifieke dingen bezig bent waarbij vergelijkingen en sorteringen heel nauw komen speelt dit waarschijnlijk niet snel een rol. Ik zou nu niet direct van defaults afwijken tenzij je op dit moment direct tegen problemen aanloopt.
Dus als ik het goed berijp hoef ik me niet druk te maken als ik overal utf-8 heb?
Indien je in MySQL enkel utf8-encoderingen gebruikt, en vervolgens ook utf8-collations dan lijkt mij dat goed, als je dat bedoelt.
Hoe bedoel je specifieke dingen?
Characters vergelijken/sorteringen die 2 of meer bytes bevatten (zogenaamde multibyte characters) ?
Sorteerregels in specifieke talen, zoals Duits en ook andere (weet zo gauw niet welke). Waarbij bepaalde karakters niet noodzakelijkerwijs "onze" natuurlijke (alfabetische) volgorde / karaktermatching zou volgen.
Zoals ik al eerder zei, zolang die niet direct voor problemen zorgt hoef je toch ook niets te veranderen (Dat bedoelde ik met If it ain't broke, don't (try to) fix it).
Het enige wat je in principe hoeft in te stellen bij het opstellen van een tabel is de character encoding volgens mij (correct me if I'm wrong) ik denk dat MySQL zelf wel zo intelligent is dat 'ie geen latin1 collation pakt bij een utf8 tabel... En anders bekijk je dit met een SHOW CREATE TABLE statement.
EDIT: daarnaast kun je in je query zelf ook schuiven met case-sensitiviteit. Zo kun je een case-sensitive collated kolom case-insensitive vergelijken (of andersom) door in je query gebruik te maken van COLLATE.
Het enige wat je in principe hoeft in te stellen bij het maken van je database connectie is je character encoding (middels een _set_charset() functie). Als je dan toch utf8-tabellen gebruikt zou 'utf8' als character encoding wel een logische keuze zijn (of een utf8-variant die meer "multibytes" ondersteunt), daarnaast zou je document ook UTF-8 moeten zijn zodat alles in de pas loopt en er niets vertaald hoeft te worden van character encoding A naar character encoding B (waar je dan ook rekening mee zou moeten houden in je _set_charset() aanroep).
That is all. Als de bovenstaande vuistregels niet afdoende zijn zul je moeten kijken wat er aan de hand is, anders lijkt mij dit genoeg.
EDIT: en om (nogmaals) terug te komen op je oorspronkelijke vraag: als een tabel/kolom een specifieke collation heeft ingesteld, dan heeft deze naar alles waarschijnlijkheid ook prioriteit op een bovengelegen collation, waarbij de default collation je default "fallback" is met de laagste prioriteit.
Voor het Nederlands geldt dat ook. Stel dat iemand zoekt op een, moet de WHERE … LIKE '%een%' dan uitsluitend een of ook één vinden? De functionele logica van je applicatie bepaalt dus wat de beste collatie is voor bepaalde query's.
