Omgaan met karaktersets MYSQL
Na wat leeswerk op internet over MySQL karaktersets en collatie blijf ik met vragen zitten. Een van de vragen betreft het volgende.
Ik lees dat veelal utf8_general_ci of of latin1_swedish_ci standaard gebruikt worden.
En dat ci in deze namen betekent : Case insesitive. Met testquery :
Select * from tabel where naam=’jan’ geeft als resultaat zowel JAN als jan.
Dit lijkt mij toch regelmatig niet handig. Dus vraag ik mij af hoe hier mee omgegaan wordt.
Ik zou zo veel mogelijk vermijden WHERE clausules te gebruiken op velden waar speciale tekens in voorkomen.
Wij passen op werk alleen nog maar UTF8 toe, zonder ci (overigens geen MySQL).
Check ook even de Collatie topic van vandaag.
Toevoeging op 23/12/2010 15:03:09:
Kris Peeters op 23/12/2010 14:59:27:
Ik zou zo veel mogelijk vermijden WHERE clausules te gebruiken op velden waar speciale tekens in voorkomen.
Wat is dit voor advies? In een beetje administratie heb je toch wel WHERE clausules op naam, adres en woonplaats waar allerlei tekens in voor kunnen komen. We leven niet meer in het COBOL tijdperk met alleen hoofdletters :)
Gewijzigd op 23/12/2010 15:04:42 door John D
utf8_bin Unicode (meertalig), Binair
Rest van utf is allemaal ci
latin1_general_cs West Europees (meertalig), hoofdletter gevoelig
Maar wanneer ik dus de documentatie lees gebruiken dus de meeste mensen standaard utf8_general_ci of of latin1_swedish_ci
Wordt ook beschreven in allerlei artikelen op Internet.
Dus dacht ik dat er wel methodes zouden zijn die gebruikt worden, om wat ik beschreven heb te hanteren. Daar zou ik dus meer info over willen krijgen.
-> ik weet trouwens ook niet wat het effect van Binair is in het geval boven.
Gewijzigd op 23/12/2010 15:57:53 door Ellen P
Edit:
Het heeft niet met sorteren te maken:
De keuze is eenvoudig, alle mogelijkheden zijn aanwezig:
utf8_bin: compare strings by the binary value of each character in the string
utf8_general_ci: compare strings using general language rules and using case-insensitive comparisons
utf8_general_cs: compare strings using general language rules and using case-sensitive comparisons
De keuze is eenvoudig, alle mogelijkheden zijn aanwezig:
utf8_bin: compare strings by the binary value of each character in the string
utf8_general_ci: compare strings using general language rules and using case-insensitive comparisons
utf8_general_cs: compare strings using general language rules and using case-sensitive comparisons
Gewijzigd op 23/12/2010 16:22:16 door John D
Alle utf8's zijn ci behalve die bin
Ik heb net met die bin getest, en daarmee wordt dus wel case sensitive onderscheid gemaakt.
Maar goed. mijn redenatie is, dat blijkbaar niet voor niets voor utf8_general_ci of of latin1_swedish_ci wordt gekozen door blijkbaar zoveel mensen.
En dan zullen die er toch wel oplossingen hebben, of manieren van omgang hiermee?
Dat wil ik dan graag weten. Wat is trouwens de reden om voor een CI karakterset keuze te kiezen vraag ik mij af.
Je bent even wat te cryptisch voor mij : en een zoekopdracht naar [A-Z] vindt daarom ook b.
Wat is een zoekopdracht naar [A-Z] ? Bedoel je hiermee een zoekopdracht in hoofdletters? En vindt daarom ook b? Wat is b in dit geval voor iets? CS is case sesitive. Dus blijkbaar begrijp ik je verkeerd.
Bas Cost Budde op 23/12/2010 17:03:00:
sorteervolgorde aAbB is ongetwijfeld ci niet cs en is voor mij wel wat wereldvreemd. Gebruikelijk in database land zijn Binary Sort en Linguistic Sort. Het sorteren zou los moeten staan van de toegepaste characterset. Je kiest UTF8 en on the fly moet je kunnen kiezen voor Binary Sort of Linguistic Sort.De collatie is vooral van invloed op sorteren van strings. Kies je een _cs-variant, dan wordt de sorteervolgorde aAbB, en een zoekopdracht naar [A-Z] vindt daarom ook b.
Gewijzigd op 23/12/2010 20:22:38 door Aad B