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?

Redundans var väl kanske fel term men det är ju lätt att se att om du måste lagra ENUM('en','sv') och frasen i en tabellen "innehåll" så har du en extra kolumn. Om du har en tabell som heter innehåll_sv och en som heter innehåll_en så slipper du en hel kolumn. Dessutom har du en logiskt mer klar struktur och om du har mycket information så blir den annars mer fragmenterad. Dessutom sker all läsning och skrivning till en tabell (en fil på disk) vilket kan vara en nackdel. Om du har indexerat så innehåller även index irrelevant information eftersom du normalt endast söker efter något på ett bestämt språk.

(Om du istället har en sida på fem språk med identiskt innehåll, du skulle lagra
id, språk1, text
id, språk2, text
id, språk3, text
id, språk4, text
id, språk5, text
medan jag istället lagrar
id, spr1text, spr2text, spr3text, spr4text, spr5text
det blir då enklare att söka efter saknade översättningar dessutom.)

Generella tabeller med olika beskrivningar för varje fält är inte alltid så effektivt, vilket bl.a. boken "The Art of SQL" tar upp (en utmärkt bok för att få ordning på strukturen och effektiviteten).

Att lägga till en tabell till är väl bland det enklaste man kan göra med sql? Lägga till columner är ju inte heller något större problem. Du måste ju hursomhelst anpassa skripten till att hantera flera språk. Det är ju enkel sak att lägga till en CMS-funktion för lägg till språk så har du det löst på en gång.

Jag kan inte se något annat att det mest logiskt riktiga och databasmässigt mest effektiva är att lagra separerat efter språk. Men du gör som du vill förstås. Jag använder själv gärna XML när det handlar om data som inte växer eller regelbundet förändras.

Jag vet inte om det går att kollatera för sorteringen men det är knappast effektivare och vid sökningar med WHERE så måste du ju i alla fall i så fall konvertera till rätt collation innan du söker på värdet vilket är onödigt resurskrävande.

Okej, du vinner =) Det är bara det att när det gäller större sidor med mycket information så handlar det inte om att skapa en tabell för varje språk utan kanske 20 eller 30 vilket inte känns jättekul...

Ja, det finns säkert tillfällen när min variant inte är optimal. Men jag föredrar snarare att ha informationen separerad även (eller kanske i synnerhet) om det gäller större sidor med många språk. Att ha trettio väl avgränsade tabeller är lättare att arbeta med än en hopgrötad tabell med all information i – men det är kanske en smaksak.

Och en lösning är ju inte alltid bäst för alla fall. Så du har säkerligen också rätt!… :P

Vi har väl rätt bägge två då =) Blir lätt väldigt många tabeller, 20 objekt på 20 språk resulterar i 400 tabeller och även om det går att hantera blir det lite oöverskådligt. Ingen av våra lösningar är riktigt perfekt men antar att man är så illa tvungen att anpassa sig till verkligheten ibland.

Fler åsikter i frågan från andra mottages gärna.

Jag borde egentligen sluta att tjata i den här tråden men…

Du har helt rätt i att det blir närmast ohållbart med 400 tabeller men vid ett sådant fall skulle jag nog inte komma på tanken att använda databaser. En långt bättre lösning är att ha en xml-fil för varje språk och sedan ha en xhtml-fil som hämtar sitt innehåll med XSL för varje språk (alla xml-filerna kan läggas i en mapp med samma namn som xhtml-filen för översiklighetens skull). På så sätt har du bara en enda xhtml-sida du behöver ändra i och en enda php-sida för hela siten (om du så önskar) som sköter XSLT. Sedan kan man enkelt göra en "editeringssida" och en "översättningssida" i CMS:et som kommer åt allt innehåll.

Jag tror det finns en annan ganska ny tråd om flerspråkiga sidor - men nu tror jag definitivt vi har avvikit lite väl långt från den här trådens tema…