DB Struktur mehrsprachig

[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