DB Struktur mehrsprachig

[hande]

Hallo Forum,

ich überdenke gerade eine DB-struktur und bin mir nicht ganz sicher welche die optimale (hinsichtlich Geschwindigkeit und Erweiterbarkeit) für eine 3sprachige (de, en, pl) ist.

Ich habe Produkteigenschaften, die für alle Sprachen gleich sind:

artikelnummer (Primärschlüssel)

hersteller
pic_1
pic_2
pic_3
...

dann habe ich Eigenschaften die sprachspezifisch sind

beschreibung
eigenschaften

nun frag ich mich ob es gut ist eine tabelle anzulegen mit 6 Spalten:

artikelnummer (Primärschlüssel)

beschreibung_de
eigenschaften_de

beschreibung_en
eigenschaften_en

beschreibung_pl
eigenschaften_pl

oder für jede Sprache eine eigene Tabelle.

was meint ihr ?

Danke,Gruß
hande

[buzz]

Hallo,

allein schon weil ich persönlich es für ästhetischer halt, würde ich alles in eine Tabelle packen,d.h.,
artikelnummer, hersteller, pic1, pic2, pic3, ..., beschreibung_de, eigenschaften_de, beschreibung_en, usw.

Außerdem brauchst du dann nicht immer alle gleichen Daten in 3 versch. Tabellen schreiben. Und beim auslesen brauchst du nur eine Tabelle auslesen...

Naja ich find's so praktischer, ob's schneller isch??

Gruß

[FraFu]

Hallo!

allein schon weil ich persönlich es für ästhetischer halt, würde ich alles in eine Tabelle packen,d.h.,
artikelnummer, hersteller, pic1, pic2, pic3, ..., beschreibung_de, eigenschaften_de, beschreibung_en, usw.

Gerade die Bilder schreien aber nach einer 1:N Beziehung.

mfg
  frafu

[wahsaga]

hi,

nun frag ich mich ob es gut ist eine tabelle anzulegen mit 6 Spalten:

Nein.
Kommt eine Sprachversion hinzu, müsstest du deine Tabellenstruktur erweitern - nicht gut.
Außerdem müsstest du bei jeder Operation die aktuelle Sprachbezeichnung an die Spaltennamen dranhängen - umständlich.

oder für jede Sprache eine eigene Tabelle.

Auch nicht, bloss nicht.
Daten gleicher Struktur gehören auch in die gleiche Tabelle.

Normalisiere, und nutze die Sprachversion als zusätzliches Schlüsselfeld.

id | sprache | eigenschaft | xyz
1  | de      | 1           | hurra
1  | en      | 1           | hooray
1  | de      | 2           | gelb
1  | en      | 2           | yellow

Und für die Eigenschaften, die in allen Sprachen gleich sind - Bildnamen etc. - könntest du ein zusätzliches "Sprachkürzel" 'all' o.ä. benutzen.

1  | all      | 3           | produktbild4711.jpg

Alle Eigenschaften zum Produkt mit der ID 1 in Sprache Deutsch auslesen dann über
WHERE id = 1 AND ( sprache = 'de' or sprache = 'all')
o.ä.

gruß,
wahsaga

[Sven Rautenberg]

Moin!

Kommt eine Sprachversion hinzu, müsstest du deine Tabellenstruktur erweitern - nicht gut.

Wie wahrscheinlich ist das genau?

Außerdem müsstest du bei jeder Operation die aktuelle Sprachbezeichnung an die Spaltennamen dranhängen - umständlich.

Die passende Herstellung eines SQL-Querys ist nicht wirklich kompliziert.

Der andernfalls erforderliche JOIN drückt aber ggf. die DB-Performance.

oder für jede Sprache eine eigene Tabelle.

Wäre auch eine denkbare Alternative.

Auch nicht, bloss nicht.
Daten gleicher Struktur gehören auch in die gleiche Tabelle.

Normalisierung und Performance sind zwei gegensätzliche Pole einer Skala. Wer seine Daten super normalisiert hat, hat in der Folge viele JOINs - und bei entsprechend großen Datenbanken dann ziemlich langsame Querys, auch mit Indices.

Wer andererseits seine Daten wenig normalisiert, hat zwar hohe Performance, dafür aber Daten doppelt, oder ungünstige Datenstrukturen hinsichtlich universeller Erweiterbarkeit.

Man muß abwägen, welche Stufe man anstrebt. Keinesfalls ist hier nur eine einzige erlaubte Lösung möglich.

Normalisiere, und nutze die Sprachversion als zusätzliches Schlüsselfeld.

Das ist ja auch wieder schlecht. Wenn schon normalisieren, dann richtig. Sprache als String: Pfuibäh! Da muß eine separate Tabelle "Sprache <-> Sprach-ID" her, und die Sprach-ID kommt dann in diese Tabelle:

id | sprache | eigenschaft | xyz
1  | de      | 1           | hurra
1  | en      | 1           | hooray
1  | de      | 2           | gelb
1  | en      | 2           | yellow

Und für die Eigenschaften, die in allen Sprachen gleich sind - Bildnamen etc. - könntest du ein zusätzliches "Sprachkürzel" 'all' o.ä. benutzen.

1  | all      | 3           | produktbild4711.jpg

Viel zu kompliziert. Alleine feststellen zu müssen, dass ein Kürzel in allen Sprachen gleich ist, ist aufwendig. Aber zu berücksichtigen, dass bei der Sprachabfrage nicht nur die aktuelle Sprache, sondern auch noch alle allgemeinen Ergebnisse erlaubt sind, macht die Sache noch aufwendiger. Und am Ende kommt dann mal eine neue Sprache hinzu, für die das alles nicht gilt - und schon darf man alle "all"-Kürzel auflösen.

Keine gute Idee.

- Sven Rautenberg

[wahsaga]

hi,

Kommt eine Sprachversion hinzu, müsstest du deine Tabellenstruktur erweitern - nicht gut.

Wie wahrscheinlich ist das genau?

Wir gehen doch wohl davon aus, dass dieses Produkt ein ähnlicher Expoertschlager wird wie Transrapid u.ä. ...?

Der andernfalls erforderliche JOIN drückt aber ggf. die DB-Performance.

Wieso sind JOINs _erforderlich_?

Man muß abwägen, welche Stufe man anstrebt. Keinesfalls ist hier nur eine einzige erlaubte Lösung möglich.

Nein, natürlich nicht.

Das ist ja auch wieder schlecht. Wenn schon normalisieren, dann richtig. Sprache als String: Pfuibäh! Da muß eine separate Tabelle "Sprache <-> Sprach-ID" her, und die Sprach-ID kommt dann in diese Tabelle

Man kann es natürlich auch übertreiben - aber gut, wenn du unbedingt willst - auch das erfordert keine JOINereien. Dann wird die Sprach-ID halt zu Beginn oder wenn ein Sprachwechsel ein mal ausgelesen.

Viel zu kompliziert. Alleine feststellen zu müssen, dass ein Kürzel in allen Sprachen gleich ist, ist aufwendig.

Wie meinen?
Wann und wo muss das "festgestellt" werden?
Redest du vom Einpflegen der Daten?

Aber zu berücksichtigen, dass bei der Sprachabfrage nicht nur die aktuelle Sprache, sondern auch noch alle allgemeinen Ergebnisse erlaubt sind, macht die Sache noch aufwendiger. Und am Ende kommt dann mal eine neue Sprache hinzu, für die das alles nicht gilt - und schon darf man alle "all"-Kürzel auflösen.

Wenn ich wie beschrieben mit
WHERE ... AND ( sprache = 'xyz' or sprache = 'all')
auswähle, dann sortiere ich halt noch so, dass ein eventueller 'xyz'-Datensatz mir vor dem 'all'-Datensatz geliefert wird - und verwenden nur den ersten.

gruß,
wahsaga

[Ilja]

yo,

geschwindigkeit und erwarterbarkeit sind zwei kriterien, die sich oftmals gegenseitig ausschließen so auch wohl in deinem falle.

von der geschwindigkeit ist es sicherlich besser, alles in eine tabelle zu packen. liegt auf der hand, dass eine tabelle in aller regel einen schnelleren zugriff hat, als eine abfrage mit mehreren tabellen.

für die erweiterbarkeit spricht einiges dafür, es in mehrere tabellen aufzulösen. wie schon erwähnt wurde, nicht nur die sprachen auszulagern, sondern auch die bilder, da es ganz offensichtlich eine 1:n beziehung ist.

was für dich am geeignetsten ist, hängt ganz stark von deinen vorgaben ab. zum beispiel die bilder, wenn du mit 99,999% sicherheit sagen kannst, dass maximal nur drei bilder pro datensatz vorhanden sein werden, kann man es so wie du denormalisieren. wenn du aber es offen lassen willst, ob man nicht noch mehr bilder für ein datensatz besitzen kann, dan solltest du es auf jeden fall in eine weitere tabelle auslagern.

genauso ist es für die sprachen. wenn du sagen kannst, das mit größter sicherheit keine sprachen mehr hinzukommen, dann kannst du es in eine tabelle packen. aber nicht vergessen, die begründung für die denormalisierung auch zu dokumentieren. wenn aber in zkunft weitere sprachen hinzukommen sollen, dann auf jeden fall normalisieren. nud das bedeutet etwa nicht, fürde jede sprache eine extra tabelle, sondern nur eine extra tabelle für alle sprachen, mit entsprechenden attributen der länderspezifischen kennung. das hat den vorteil, dass  du bei einer weiteren sprache NICHT och mal das datendesign ändern musst und somit auch zwangsweise ein riesiger folgeaufwand in der programierung, sondern du kannst du bestehen struktur nutzen und einfach weitere datensätze für die neue sprache einfügen.

Ilja