Struktur mit mehrsprachlichen Inhalten

[oriberu]

Hallo,

mich beschäftigt die Frage, wie ich sinnvoll mehrsprachige Inhalte in
einer Datenbankstruktur abbilden könnte; die Variante, einfach themen-
gleiche Felder mit einem Suffix versehen der Stammdatentabelle hinzu-
zufügen, scheint mir nicht sonderlich flexibel (siehe Beispiel) - kennt
eventuell jemand einen eleganten Weg oder hat einen entsprechenden
Literaturhinweis zum Thema? Danke für Eure Aufmerksamkeit.

Beispiel:

stammdaten
------------
sta_id
sta_titel_en
sta_text_en
sta_titel_de
sta_text_de

Grüße

[Rouven]

Hello,

stammdaten

sta_id
sta_titel_en
sta_text_en
sta_titel_de
sta_text_de

dieses Modell funktioniert, gar keine Frage. Das einzig wirkliche Problem ist,dass es nur sehr schwer erweiterbar ist, weil eine weitere Sprache eine Änderung am Datenmodell erfordert, etwas was man nie, nie, nie (ganz selten) machen sollte. Auf der Haben-Seite steht zumindest die einfache Handhabung.

Die erste Erweiterung wäre die Kennzeichnung eines Satzes mit seiner Sprache, also aus Spalte mach Zeile:
sta_id, sta_titel, sta_text, sprache
und als Primärschlüssel id+sprache oder nur id, je nach Belieben und Anforderungen.
Vorteil liegt in der höheren Dynamik, keiner Platzverschwendung durch unnütze Spalten, Nachteile sind noch kaum vorhanden, die Abfrage liegt eigentlich auf der Hand.

Dann gibt es noch die ganz dynamische Variante, bei der noch nichtmal vorgegeben ist, dass es titel und text gibt, sondern man dies auch noch in Zeilen auflöst.
id, info_typ, info_wert, info_sprache

• z.B. info_typ = titel
  Vorteil: Extrem dynamisch (insbesondere von Vorteil bei Kundenverwaltung wenn es an Kontaktdaten geht, Pager, Handy, was auch immer in Zukunft kommt,  fließt alles dynamisch rein), Nachteil: Das menschliche Auge ist nicht mehr in der Lage einen "Satz" zu identifizieren, der Rechner noch viel weniger, eine Abfrage besteht aus mehreren Joins.

MfG
Rouven

[oriberu]

Hallo,

danke für Deine Antwort.

dieses Modell funktioniert, gar keine Frage. Das einzig wirkliche
Problem ist,dass es nur sehr schwer erweiterbar ist, weil eine
weitere Sprache eine Änderung am Datenmodell erfordert, [...]

Ja, genau das ist es auch, was mir hauptsächlich Unbehagen bereitet.

Die erste Erweiterung wäre die Kennzeichnung eines Satzes mit
seiner Sprache, also aus Spalte mach Zeile:
sta_id, sta_titel, sta_text, sprache

Bei mir wäre eine Eintrag in der Stammdatentabelle sozusagen ein
primäres Datenobjekt, d.h. eine Zeile daraus enthält die wichtig-
sten Daten für die jeweilige Instanz des Projektes - ich habe, in
Ermangelung eines besseren Ausdrucks, ein "philosophisches" ;)
Problem damit, hier Einträge hinzuzufügen, die sich nur in den
Spracheigenschaften und der ID unterscheiden (in der Tabelle wären
dann im Einsatz auch viele nicht-sprachbezogene Eigenschaften verankert);
ich würde gern vermeiden, dass beispielsweise id #10,11,12 essentiell
die gleichen Reihen enthalten, in der sich dann jeweils nur die text-
bezogenen Felder unterscheiden. Ich hatte bei meinem Besipiel der
Übersichtlichkeit halber auf die neutralen Felder verzichtet; das war
wahrscheinlich nicht ganz günstig, sorry. Ich ziehe die Möglichkeit
auf jeden Fall in Betracht.

Dann gibt es noch die ganz dynamische Variante, bei der noch
nichtmal vorgegeben ist, dass es titel und text gibt, sondern man
dies auch noch in Zeilen auflöst.
id, info_typ, info_wert, info_sprache

• z.B. info_typ = titel

Darüber habe ich grundsätzlich auch nachgedacht; ich bin mir aller-
dings nicht sicher, wie diese Daten dann zu referenzieren wären. Das
würde doch in etwa dieses Modell voraussetzen:

stammdaten        info                 typ         sprache
------------      ---------            --------    ---------
sta_id            inf_id               typ_id      spr_id
sta_name          inf_typ_id -->       typ_name    spr_kuerz
sta_bla           inf_wert                         spr_name
sta_info_id ???   inf_sprache_id -->

--> 1:n Relation

Denn hier könnte ich aus stammdaten ja jeweils nur einen info-Datensatz
referenzieren. Hmm, oder ich setze in info gleich noch ein zusätzliches
ID-Feld ein, in dem dann die sta\_id referenziert ist, dann hat dort noch
immer jeder Datensatz einen eigenen Identifikator, kann von einer Applikation
aber trotzdem noch zugeordnet werden. Verstöße das gegen die "reine Lehre",
weil dann keine direkte Referenz aus meiner stammdaten-Tabelle hervorgeht?

Also wie eben, nur mit zwei abgewandelten Tabellen:

stammdaten      info
------------    ---------
sta_id          inf_id
sta_name        inf_stammdaten_id
sta_bla         inf_typ_id -->
                inf_wert
                inf_sprache_id -->

Grüße

[Rouven]

Hello,

wie gesagt, das volldynamische Modell ist relativ unübersichtlich. Um nochmal das Beispiel mit dem Adressverzeichnis aufzugreifen:

stammsatz
id | name | vorname
-------------------
1  | abc  | def
2  | hij  | klm

kontaktinfo
stamm_id | typ_id | sprache | wert
----------------------------------------
1        | 1      | de      | 12345
1        | 2      | de      | [e-mail]
...

typ
id | beschreibung
-----------------
1  | Telefonnummer
2  | E-Mail-Adresse

Du hast in der Tat eine 1:n Beziehung, mittels derer du einer Person alles notwendige zuordnen kannst. Ein Filter auf stamm_id (und Sprache) liefert die gewünschten Informationen, ggf. unter Hinzunahme der typ-Tabelle.

Nochwas: In diesem Beispiel ist die Sprache an die Attributausprägung gebunden, während der Attributtyp nur in Deutsch beschrieben ist. Das ist nur bedingt sinnvoll, wenn man beispielsweise aus der Beschreibung automatisch Formulare generieren will. In diesem Fall könnte man sich überlegen, dass die E-Mail-Adresse ja kein englischsprachiges Merkmal ist, demnach keine Sprachinformation braucht (-> sprache aus kontaktinfo raus). Dafür ist es aber wichtig zu wissen, ob es 'E-Mail-Adresse' oder 'e-mail address' heißt (-> also Sprachkennung in die typ-Tabelle mit rein). Und dann kann man natürlich noch beide Varianten kombinieren um beides sprachspezifisch zu halten. Und wenn man ganz wild drauf ist, dann schreibt man statt sprache 'de' stattdessen eine Sprachid und legt dafür noch eine Tabelle an.

Was will ich sagen? Viele Wege führen nach Rom. Wichtigster Unterschied zu deinem Posting, sofern ich dich jetzt richtig verstanden habe, die 1:n Beziehung war bei dir falsch herum aufgebaut, die n-Seite muss immer zurück auf die 1-Seite verweisen, nicht anders herum.

MfG
Rouven

[s.oliver]

Hallo,

wie gesagt, das volldynamische Modell ist relativ unübersichtlich.

ich werde es wahrscheinlich trotzdem verwenden, da ich in diese
Struktur sprachbezogene Werte aus anderen Tabellen ebenfalls ohne
viel Federlesens eingliedern kann. Zudem wird die betroffene Datenbank
ohnehin nur von einem (dann dementsprechend dokumentierten) Skript
frequentiert und ich bin zudem bestrebt, die Tabellen- und Feldnamen
möglichst intuitiv zu wählen.

Um nochmal das Beispiel mit dem Adressverzeichnis aufzugreifen:

Trotzdem auch danke dafür.

Nochwas: In diesem Beispiel ist die Sprache an die
Attributausprägung gebunden, während der Attributtyp nur in Deutsch
beschrieben ist. Das ist nur bedingt sinnvoll, wenn man
beispielsweise aus der Beschreibung automatisch Formulare
generieren will. [...]

In der Produktionsumgebung werden alle Datenbanken, Tabellen und
Attribute in englischer Sprache und nach den gleichen Konventionen
geformt sein. Strukturelemente von Applikation/Webseite/Skript haben
meiner Ansicht nach in einer Datenbank ohnehin nichts verloren; diese
Daten werden dann unabhängig von den Daten in der DB über eigene
Lokalisierungsfunktionen und Konversionstabellen in den Masken
erzeugt und angepasst.

[...] die 1:n Beziehung war bei dir falsch herum aufgebaut, die
n-Seite muss immer zurück auf die 1-Seite verweisen, nicht anders
herum.

Danke für den Hinweis.

Grüsse

[s.oliver]

Oh, und nicht verwirren lassen: oriberu == s.oliver; ich benutze
verschiedene, voreingestellte Benutzernamen an verschiedenen Rechnern
bzw. zu verschiedenen Zeitpunkten.

[AAA]

Hallo,

wie wäre es denn auf folgende Weise:

sta_id  sta_lang  sta_titel   sta_text
======  ========  ----------  ---------
1       en        My title    My text
1       de        Mein Titel  Mein Text

Der Primärschlüssel wäre in diesem Fall aus "sta_id" und "sta_lang" zusammengesetzt. Somit ist das Ganze auf beliebig viele Sprachen erweiterbar.

Schöne Grüße.

[oriberu]

Hallo,

sta_id  sta_lang  sta_titel   sta_text
======  ========  ----------  ---------
1       en        My title    My text
1       de        Mein Titel  Mein Text

Der Primärschlüssel wäre in diesem Fall aus "sta_id" und "sta_lang"
zusammengesetzt. Somit ist das Ganze auf beliebig viele Sprachen erweiterbar.

danke für Deine Antwort.

Falls Du dies hier lesen solltest, wirf bitte auch einen Blick auf meine
Antwort zu Rouens Beitrag, in dem ich auf einen ähnlichen Vorschlag geant-
wortet habe.

Ich habe ehrlich gesagt ein Problem damit, den Primärschlüssel "aufzuweichen"
und auf verschiedene Komponenten zu verteilen (ein Prinzip welches ich, wenn
ich ganz ehrlich bin, mir vor vielleicht acht Jahren mal angelesen, und dann
prompt wieder vergessen habe ;) - ich versuche, eine bestimmte Hierarchie in
der Datenbank zu haben, bei der ein "Stammdatensatz" (also der Datensatz der
Haupttabelle) möglichst einzigartig sein soll, und Facetten oder Variationen
von Daten dann in Sekundärtabellen aufgeführt sind; mir fehlte für die
Sprachenproblematik nur ein möglichst barrierefreier Ansatz. Ich sehe aber
durchaus die Vorteile des von Dir vorgeschlagenen Prinzips, mit dem ich mich
auf jeden Fall näher auseinandersetzen werde.

Grüße