tabel structuur meertalige website

[ieperlingetje]

Ik wil een test maken om mijn website meertalig te maken. Ik wil de artikelen opslaan in de database, zover is de tabelstructuur geen probleem (artikelID, currentLang, inhoud). Echter, nu wil ik bij elke artikel ook een link plaatsen naar een artikel in een andere taal (en dus ook een ander ID).
Eerst dacht ik het op te lossen op deze manier
(artikelID, inhoudNL, inhoudEN, inhoudFR), hierbij kan ik wel linken naar andere talen, maar wat als een bepaalde tekst nog niet vertaald is in alle talen? Dan zit ik weer met verspilde ruimte.
Ik ga dus zowiezo een koppelingstabel nodig hebben, maar hoe moet ik dat aanpakken?
iets als (artikelID, currentLang, artikelID_NL, artikelID_EN, enz...) is ook niet handig voor normalisatie, daarbij met de andere artikelID's moet ik dan weer het proces herhalen. Ik weet dat de beste manier voor mijn tabel ongveer
(artikelID, currentLang, inhoud) is, maar dan weet ik niet hoe ik artikels in andere talen moet gaan opzoeken.

Iemand een idee hoe ik dit oplos?

[HuHu]

Je moet geen apart artikelID nemen voor hetzelfde artikel, maar dan in een andere taal. Maak een tabel waarbij de primary key bestaat uit artikelID + currentLang. Dan kun je eenvoudig een artikel pakken en vertalen (door de currentLang te veranderen) of opzoeken in welke talen het beschikbaar is (welke currentLang heb je voor artikelID).

Hernoem currentLang dan ook meteen naar lang of langID.

[RobIII]

ieperlingetje schreef op woensdag 03 maart 2010 @ 15:39:
maar wat als een bepaalde tekst nog niet vertaald is in alle talen? Dan zit ik weer met verspilde ruimte.

Euh, nee Waarom zou een leeg veld (op wat overhead na) ruimte kosten? (Tenzij het geen varchar/text is maar char). En dan nog: wat boeit het Zo duur is een paar MB schijfruimte niet hoor

ieperlingetje schreef op woensdag 03 maart 2010 @ 15:39:
Ik weet dat de beste manier voor mijn tabel ongveer (artikelID, currentLang, inhoud) is, maar dan weet ik niet hoe ik artikels in andere talen moet gaan opzoeken.

SQL:

Select ... where artikelid = 123 and currentlang = 'nl'

Als je een compound key gebruikt (dus pk = artikelid + currentlang) dan is er geen probleem. Wat HuHu dus zegt. Dan krijg je:

artikelid	currentlang	inhoud
123	nl	Blablabla bla bla
123	en	Blahblahblah blah blah
123	fr	Du pain, du vin et du boursin

En dan valt er nog te twisten over je benamingen (artikelid = articleid of contentid bijvoorbeeld en 'current' lijkt me een overbodige toevoeging aan 'langid') en je en/nl mix in de benamingen die je gebruikt. Wees daar consistent in.

[ Voor 29% gewijzigd door RobIII op 03-03-2010 16:01 ]

[cariolive23]

Met genoemde oplossingen kun je ook een nieuwe taal en content toevoegen zonder dat je database en al je code op de schop moet. Scheelt een flinke bak werk!

[ieperlingetje]

Bedankt voor het idee van die compound key. (Had ik eigenlijk ook wel zelf moeten weten terwijl ik bezig was met de normalisatie )

[Alex]

Overigens, beetje mosterd na de maaltijd, maar meestal kun je voor dit soort zaken een CMS gebruiken . Deze zijn er in vele smaken en varianten(zowel betaald als onbetaald) en zijn vaak een stuk productiever op dit vlak.

[Wolfboy]

Een NULL veld neemt (zoals Rob III zegt) nauwelijks ruimte in, daar hoef je echt geen rekening mee te houden.

En je kan het dan direct ophalen met iets als COALESCE(inhoudNL, inhoudEN)

[mcdronkz]

Wolfboy schreef op donderdag 04 maart 2010 @ 14:06:
Een NULL veld neemt (zoals Rob III zegt) nauwelijks ruimte in, daar hoef je echt geen rekening mee te houden.

En je kan het dan direct ophalen met iets als COALESCE(inhoudNL, inhoudEN)

Op die manier moet je database nog steeds op de schop als je een nieuwe taal wilt toevoegen, of begrijp ik het verkeerd?

[Wolfboy]

mcdronkz schreef op dinsdag 09 maart 2010 @ 19:49:
[...]


Op die manier moet je database nog steeds op de schop als je een nieuwe taal wilt toevoegen, of begrijp ik het verkeerd?

Dat begrijp je goed. Of dat wel/niet acceptabel is hangt natuurlijk van je use-case af. Als je weet dat je altijd een vast (klein) aantal talen gaat hebben dan kan dat imho prima. Is dat niet het geval dan moet je dit zeker niet doen.

Als je het netjes wil doen dan denormaliseer je het allemaal, doe je een left join op de language tabel en haal je met coalesce de goede waarde op. Werkt ook prima, stuk netter, maar is ietwat trager en maakt een query net iets lastiger.