Finns det några egentliga fördelar med att köra de specifika utf8_[blablabla]_ci som collation gentemot utf8_general_ci?

Kan tänka mig att sortering påverkas

Om du vill ha korrekt sortering på svenska måste du använda utf8_swedish_ci, detsamma gäller för de flesta språk.

Dessutom kan det påverka WHERE-satser, eftersom a och ä är olika bokstäver på svenska men samma bokstav (fast med umlaut) på engelska och tyska.

WHERE ord LIKE 'ä%'
ger alltså olika resultat beroende på språkinställningen.

Jag misstänkte att sorteringen kunde påverkas. Om man ska erbjuda flerspråksstöd på en sida blir man ju så illa tvungen att köra utf8_general_ci iaf eller hur gör ni andra om ni ska ha texter på flera olika språk i samma tabell?

Jag vet att jag fick bättre resultat med "utf8_bin", dock var det ett tag sen så jag minns ej vilka språk det handlade om...

"Bättre" innebär att sortering fungerade lika bra eller nästan lika bra som om man hade haft de specifika språken? Kör man utf8_bin så kan man inte läsa texten direkt i phpmyadmin förmodar jag?

Har du flera språk så sätter du rätt språk i varje fält. Har du flera språk i samma fält så har du nog inte så stor ordning på strukturen (eller använder den på något märkligt sätt).

Sätt alltså collation för varje kolumn precis som du bestämmer andra typer, TINYINT, SMALLINT etc efter behov.

Har man flera språk så har man ju ofta flera språk i samma kolumn med något ID som anger språket.

Det låter för min del som en ganska korkad lösning just eftersom man då inte kan dra nytta av sortering och sökning som MySQL annars sköter fantastiskt bra. En smartare lösning är att ha enskilda tabeller för olika språk, t.ex. nyheter_sv, nyheter_en osv., om det handlar om olika artiklar som inte alltid är översatta till alla språk, eller om det hanlar om identiskt (men översatt) innehåll istället i en tabell med olika språk t.ex. title_sv, title_en, title_fr, link_sv, link_en, osv.

Du slipper redundas, kan direkt se vad som är null:at och behöver översättas och har lite mer struktur på innehållet då. Men det är ju en smakfråga så man kan ju gör som man vill, men lite dumt är det ju i synnerhet om man helt plötslig behöver t.ex. turkisk sortering och har alla språk i en kolumn, då får du ju sköta sorteringen på skriptsidan vilket ju inte är så lyckat. :rolleyes:

För övrig är inte "ett id, en sortbeskrivning, ett innehåll"-lösningen generellt särskilt lyckad eftersom du egentligen har ett redundant fält (sortbeskrivningen, som t ex anger språk). Det ser översiktligt ut och blir inte lika komplext som andra lösningar men kan straffa sig ordentligt i längden.

För min del skulle jag välkomna om man även kunde "kollatera" datum och decimaltal med t.ex
kronor DECIMAL COLLATE utf8_currency_sweden
eller
skickat DATE COLLATE utf8_swedish_full

För att direkt få ut t.ex. 18 Maj 1993 utan att använda DATE_FORMAT() och kunna hantera valutor och få ut t.ex. € 14,50 (med collation uft8_currency_europe) direkt utan att använda funktioner.

Det blir egentligen ingen redundans då man ändå vill ange språk på varje artikel på något vis. Det känns också ganska omständigt att behöva skapa en mängd nya kolumner eller tabeller varje gång man ska lägga till ett nytt språk?

Vill man helt plötsligt ha turkisk sortering så vill man förmodligen ha det endast på det som är skrivet på turkiska och det går väl att lägga kollationering direkt i sorteringen i sql-satsen oavsett vilken kollationering som råder i tabellen?