nicht angemeldet
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 | test@example.com
...
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
-------------------
Buy when there's blood running in the street and sell when everyone is pounding at your door, clawing to own your equities -- Wisdom on Wallstreet