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…