Adressdatenbank-Problem

[Tom]

Hello,

keine schönen. Es gibt noch das hochdynamische Modell:
eigenschaften
typ | name

1   | telefonnummer
2   | name
3   | email

angestellte
id  | fk_typ | wert

1   | 1      | 0123-456789
1   | 2      | Test
1   | 3      | [e-mail]
1   | 3      | [e-mail]

Das ist nur sehr schwer lesbar und relativ aufwändig in der Verwaltung. Es bietet aber volle Flexibilität ggü. möglichen Änderungen.

Das ist aber z.B. mit allen Datenbanken, die VarChar automatisch verwalten, die beste Lösung. Access kann damit z.B. ganz excellent ungehen.
Auch mit MySQL lässt sich das bequem abbilden.

Das Problem ist der Spaltentyp der Spalte "wert".
Wenn dessen Spaltenbreite nicht dynamisch verwaltet werden kann, dann kann dieses Modell zielmlich schnell zum Speicherplatz-GAU werden. Man müsste theoretisch auch den darzustellenden Datentyp dazu abspeichern. Natürlich nicht für telefonnummern oder eMails, aber z.B. bei Eigensschaften technischer Produkte...

Alternativ kann man auch typgerecht speichern. dann muss die Relation über einen Datenwert gesteuert werden, damit man ermitteln kann, in welcher Spaltentyp-Tabelle der Datenwert gelandet ist.

angestellte
 id  | tabelle   | id_tabelle
 -------------------
 1   | T_Deciaml | 233
 1   | T_Text    | 1077
 1   | T_Float   | 7777
 1   | T_Datum   | 3

Und die typgerechten tabellen

T_Decimal
---------------------------------
id   | wert
---------------------------------
10   | 123456.22
100  | 2789.13
233  | 0.00
1000 | 696

usw...

Das Beispiel stellt die Diskrepanz zwischen logischer und physischer Normalisierung dar.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom