[alg/DB model] Multilanguage DBModel

[Antediluvian]

Ik zit al geruime tijd met een bepaald probleem bij het modellen van een rationale database die meerde talen moet ondersteunen.

Stel, men heeft een tabel product en dat product heeft een naam en omschrijving in meerdere talen. Hoe breng je dit best in model?

Tot zo ver ken ik 2 manieren:

1) Een tabel met verschillende kolomen voor de verschillende talen:

code:

    +--------------------+
    |    Product         |
    |--------------------|
    |  + ID              |
    |  - NameNL          |
    |  - NameFR          |
    |  - NameEN          |
    |  - DescNL          |
    |  - DescFR          |
    |  - DescEN          |
    |  - ...             |
    +--------------------+

(+ = primary key)

2) Een relatie tussen de tabel Product en een tabel Language

code:

+--------------------+       +--------------------+       +--------------------+
|    Product         |       |    P_L             |       |    Language        |
|--------------------|       |--------------------|       |--------------------|
|  + ProductID       |       |  + ProductID       |       |  + LanguageID      |
|  - Price           |       |  + LanguageID      |       |  - LanguageName    |
+--------------------+       |  - Name            |       +--------------------+
                             |  - Description     |
                             |  - ...             |
                             +--------------------+
(+ = primary key)

Beide methodes heb ik reeds toegepast. Mijn bevindingen:

Methode 1
+ Makkelijk in ontwerp
+ Makkelijk in gebruik (voor het ontwikkelen van de middle tier)
+ Sneller (geen inner joins nodig)

- Slecht flexibiliteit (extra taal toevoegen vraagt extra aanpassing in de DB en de middle tier)

Methode 2
+ Maximum flexibiliteit

- Complexiteit
- Trager (altijd is er een inner join nodig)


Wat is volgens jullie de beste methode?
Misschien kennen jullie nog beter manieren?
Welke methode zou je kiezen bij het ontwikkelen van een groot/klein systeem en waarom?

[ Voor 4% gewijzigd door Antediluvian op 03-09-2004 12:41 ]

[NMe]

Als het aantal talen in het begin vast staat zou ik me houden aan optie 1, maar mijn persoonlijke voorkeur gaat nog altijd uit naar een goed genormaliseerde database zoals in optie 2. Flexibiliteit en minder redundantie gaan bij mij altijd voor. Veel complexer en trager is het overigens ook niet, als je het eenmaal gewend bent.

[whoami]

Een INNER JOIN is helemaal niet zo traag hoor. Ik zou zeker voor optie 2 gaan.
Het is flexibeler, beter onderhoudbaar, etc....
Het is dan ook een relationele DB , en die DB's zijn ontworpen met joins in het achterhoofd.

Je zou misschien hier eens naar kunnen naar kijken:
[rml][ Alg] Generiek multi-language systeem[/rml]

[Antediluvian]

Ik weet dat een INNER JOIN in principe niet traag(er) is maar in een uitgebreid systeem zullen al die inner joins toch een invloed op de snelheid hebben.

Vooral de complexiteit is verontrustend

Stel:

Product heeft een ProductStatus en die heeft ook een naam/omschrijving in verschillende talen.

Een product heeft een n:m relatie met ProductGroep die alweer een naam en omschrijving heeft in verschillende talen.

...

[Antediluvian]

Even een Model waarin de complexiteit duidelijk word.
click voor groter en duidelijker formaat

[whoami]

Momenteel ben ik bezig met een complex , en ik kan zeggen dat het zeker performant genoeg is.

[farlane]

Antediluvian schreef op 03 september 2004 @ 00:15:
Even een Model waarin de complexiteit duidelijk word.

Mag ik vragen waarmee je dat model hebt getekend? Ziet er wel flex uit namelijk ...

[pjonk]

Voor een PHP/MySQL website heb ik ook jouw 1e methode met NameNL,NameUK gebruikt, maar ik heb het daarna omgebouwd naar de genormaliseerde methode en ik vind dit veel prettiger werken:
- Je queries zijn beter leesbaar. Bij de 1e methode moet je bij het ophalen van data steeds die language suffix eraan plakken. Nu hoef je alleen een WHERE LanguageID = te gebruiken
- Je houdt je tabellen overzichtelijk (geen redundantie)

Maar waarom eigenlijk 3 tabellen? 2 tabellen lijkt mij genoeg:

code:

+--------------------+       +--------------------+
|    Product         |       |    Language        |
|--------------------|       |--------------------|
|  + ProductID       |       |  + LanguageID      |
|  + LanguageID      |       |  - LanguageName    |
|  - Name            |       +--------------------+
|  - Description     |
|  - ...             |
+--------------------+
(+ = primary key)

[Creepy]

JonkieXL schreef op 03 september 2004 @ 10:06:
- Je houdt je tabellen overzichtelijk (geen redundantie)

Maar waarom eigenlijk 3 tabellen? 2 tabellen lijkt mij genoeg:

code:

+--------------------+       +--------------------+
|    Product         |       |    Language        |
|--------------------|       |--------------------|
|  + ProductID       |       |  + LanguageID      |
|  + LanguageID      |       |  - LanguageName    |
|  - Name            |       +--------------------+
|  - Description     |
|  - ...             |
+--------------------+
(+ = primary key)

Omdat je niet taalspecifieke procucteigenschappen nu redundant in je DB komen te staan.

[Janoz]

Ikzelf ga voor optie 3 .. Ik gebruik geen koppel tabel. Bij het project waar ik nu mee bezig ben heb ik bijvoorbeeld meerdere taal versies van een document. De gedeelde data (id, search labels en category id) gooi ik in de ene tabel terwijl ik in de andere tabel een documentid taalid en taal specifieke dingen gooi (de content, titel en de bestandsnaam).

Ik zit nu alleen nog een beetje vast in de naamgeving. Ik heb nu Documents en localizedDocuments, maar dat is veel te lang .

[pjonk]

Creepy schreef op 03 september 2004 @ 10:14:
[...]

Omdat je niet taalspecifieke procucteigenschappen nu redundant in je DB komen te staan.

Dat is waar, maar voor mijn website betekent dit dat ik voor de tabellen downloads, producten en product categorieën 3 extra vertaal tabellen nodig heb.
Plus als ik data van een product wil ophalen, niet taalafhankelijk en taalafhankelijk moet ik met 2 tabellen gaan joinen.
IMHO zou een mooie oplossing zijn om 1 vertaal tabel te gebruiken om zo het aantal tabellen een beetje in te perken.

[Antediluvian]

farlane schreef op 03 september 2004 @ 10:02:
Mag ik vragen waarmee je dat model hebt getekend? Ziet er wel flex uit namelijk ...

DBDesigner 4
http://www.fabforce.net/dbdesigner4/

General Information - What is DBDesigner 4?

DBDesigner 4 is a visual database design system that integrates database design, modeling, creation and maintenance into a single, seamless environment.

It combines professional features and a clear and simple user interface to offer the most efficient way to handle your databases.

DBDesigner 4 compares to products like Oracle's Designer©, IBM's Rational Rose©, Computer Associates's ERwin© and theKompany's DataArchitect© but is an Open Source Project available for Microsoft Windows© 2k/XP and Linux KDE/Gnome. It is release on the GPL.

[farlane]

Antediluvian schreef op 03 september 2004 @ 12:29:
DBDesigner 4
http://www.fabforce.net/dbdesigner4/

Dank

[Antediluvian]

Is er niemand anders die dit probleem voor heeft of voor een soortgelijke keuze staat?