Adressdatenbank-Problem

[Hans]

Hi, ich habe eine Datenbank mit Namen und Telefonnummern bzw. Emailadressen:

Angestellte-DB
AID|Vorname|Nachname|Emailadresse|Telefonnummer|Mobil|Fax

Soweit so gut, was ist nun aber, wenn ein Angestellter mehrere Emailadressen hat oder mehrere Handynummern ?

dann komme ich nicht umhin nochmal zwei Tabellen zu machen, oder?
Eine für Emailadressen und eine Für Telefonnumern?

Oder gibt es da noch eine andere Möglichkeit ?

[Rouven]

Hello,

Oder gibt es da noch eine andere Möglichkeit ?

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.

Eine andere Möglichkeit bietet noch objekt-fähige Datenbanken wie Oracle, DB2 oder der MS-SQL-Server, da kannst du deine E-Mail-Spalte als Array von Werten o.ä. deklarieren, aber schön ist IMHO was anderes...

MfG
Rouven

[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

[hans]

Oh entschuldigung, die Datenbank ist Access. Genau so habe ich das gedacht, mit dem hochdynamischen Modell.

Nur eben je eine Tabelle

Angestellte
Emailadressen (mit Fremdschlüssel AngestelltenID)
Nummern (mit Fremdschlüssel AngestelltenID)

so hätte ich volle Flexibilität und so wäre es nicht soo schwer auslesbar. Dann spricht da also nichts dagegen?

[Stefan]

Hi,

Oder gibt es da noch eine andere Möglichkeit ?

kommt drauf an. Du scheibst weder welche DB noch mit welcher Software du diese ansprichst.

Ich habe ein ähnliches Adressbuch und Felder wo meherer Werte möglich sind füge ich komplett mit einem Trennzeichen ein. So kann ich mit PHP das wunderbar als Array auslesen.

Stefan