MySQLi Collation
Ik heb even een kort vraagje..
Moet de MySQLi verbinding collatie hetzelfde zijn als de collatie van een tabel/tabelkolom?
Dus is toegestaan dat de MySQLi verbinding collatie utf8_general_ci is en de tabel/tabelkolom utf8_unicode_ci is?
Heeft het consequenties?
Zoals dat er rare tekens komen ofzo?
Ik kwam hierachter toen ik dit deed (nadat ik set_charset gebruikte):
Code (php)
1
print_r($db->get_charset());
En dit mijn resultaat is:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
stdClass Object
(
[charset] => utf8
[collation] => utf8_general_ci
[dir] =>
[min_length] => 1
[max_length] => 3
[number] => 33
[state] => 1
[comment] => UTF-8 Unicode
)
(
[charset] => utf8
[collation] => utf8_general_ci
[dir] =>
[min_length] => 1
[max_length] => 3
[number] => 33
[state] => 1
[comment] => UTF-8 Unicode
)
Alvast bedankt!
Gewijzigd op 13/12/2015 17:50:12 door Marthijn Buijs
en later in dezelfde thread
Collation is niet hetzelfde als character encoding!
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.
If it ain't broke...
Gewijzigd op 13/12/2015 19:00:30 door Thomas van den Heuvel
Quote:
Tenzij je met hele specifieke dingen bezig bent waarbij vergelijkingen en sorteringen heel nauw komen speelt dit waarschijnlijk niet snel een rol.
Hoe bedoel je specifieke dingen?
Characters vergelijken/sorteringen die 2 of meer bytes bevatten (zogenaamde multibyte characters) ?
Gewijzigd op 13/12/2015 20:56:20 door Marthijn Buijs
Quote:
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.
Quote:
Hoe bedoel je specifieke dingen?
Characters vergelijken/sorteringen die 2 of meer bytes bevatten (zogenaamde multibyte characters) ?
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.
Gewijzigd op 13/12/2015 21:29:59 door Thomas van den Heuvel
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.