MySQL ENUM Ersatz

[Chrisi]

Hallo zusammen,

ich setze gerade eine MySQL Datenbank auf und möchte für Adressdatensätze einen Typ festlegen:

invoice
shipping

Ich möchte aber nur ungern eine ENUM-Spalte nutzen, daher meine Frage wie bildet man solche Spalten in einer Tabelle sinnvoll ab?

Eine Idee wäre Extraspalten:

is_invoice (0,1)
is_shipping (0,1)

Und hier dann gleich die Frage hinterher ob es sinnvoller ist Y/N oder 0/1 als Werte für einfache Wahr oder Falsch Spalten zu verwenden?

Danke für eure Hilfe und Viele Grüße.
Chrisi

[EKKi]

Mahlzeit Chrisi,

ich setze gerade eine MySQL Datenbank auf und möchte für Adressdatensätze einen Typ festlegen:

invoice
shipping

Ich möchte aber nur ungern eine ENUM-Spalte nutzen, daher meine Frage wie bildet man solche Spalten in einer Tabelle sinnvoll ab?

Erstelle eine neue Tabelle namens "Adressdatensatztyp" (o.ä.) mit den beiden Einträgen

ID | Name
---+----------
 1 | invoice
 2 | shipping

(o.ä.) und ergänze Deine Tabelle "Adressdatensatz" (oder wie immer sie heißen mag) um eine Spalte "AdressdatensatztypID" (o.ä.).

Informiere Dich zum Stichwort "Normalisierung".

Eine Idee wäre Extraspalten:

is_invoice (0,1)
is_shipping (0,1)

Genau - und wenn dann irgendwann der nächste Adressdatensatztyp dazukommt, passt Du einfach die Tabelle und alle Abfragen, Skripte und Programme an - ist ja schnell gemacht ...

Nicht am falschen Ende sparen!

MfG,
EKKi

[Chrisi]

Hallo EKKi,

danke für deine Antwort, Normalisierung ist ein gutes Stichwort mit dem ich heute den Rest des Tages verbringen werde :)

Viele Grüße
Chrisi

[Chrisi]

Hallo EKKi,

Genau - und wenn dann irgendwann der nächste Adressdatensatztyp dazukommt, passt Du einfach die Tabelle und alle Abfragen, Skripte und Programme an - ist ja schnell gemacht ...

Mir ist da noch was eingefallen :)

Ich habe 4 Tabellen:

kunden
adressen
adressen_typen
rechnungen

-> Jede Rechnung gehört zu einem Kunden
-> Es soll optional eine abweichende Lieferadresse auf der Rechnung ermöglicht werden

Jetzt habe ich mir das so ausgemalt das ich eine Tabelle für die AdressTypen anlege und in der Tabelle Adressen immer den Typ merke. Aber was mache ich in der Tabelle für die Rechnungen wenn es eine Rechnungs- und eine Lieferadresse geben soll die beide auf eine andere id_adressen verweisen?

Tabelle rechnungen
  -> id, id_adressen_invoice?, id_adressen_shipping?, ...

In den Spalten den Typ zu setzen ist vermutlich genauso falsch wie den Typ fest bei den Adressen zu speichern.

Ein anderer Ansatz über die, Tabelle adressen
  -> id, groupid, typ, ...

Macht es Sinn hier noch eine weitere id "groupid" oder sowas zu nutzen um grundsätzlich die versch. AdressenTypen die zusammengehören zu gruppieren?
Somit müssten in der Tabelle adressen immer soviele versch. Adressdatensätze zu finden sein wie es versch. Adresstypen gibt.

Hat sich hierzu schonmal jemand Gedanken gemacht?

Viele Grüße und Danke
Chrisi

[Frank (no reg)]

Hallo, bin zwar nicht Ekki ... aber egal.

Wenn ich dein Problem richtig verstanden habe, dann würde ich folgendes zu Kunde geben:

• Adresse ist Adresse, eine Adresse selbst sollte nicht durch einen kontext-losen Typen klassifiziert werden
• stattdessen sollte die Klassifizierung im Kontext erfolgen, und dieser ist "RECHNUNG"

d.h. entweder du legst mehrere Spalten an wie in deinem Beispiel oder du erzeugst eine Tabelle zwischen Rechnungen und Adressen, bestehend aus "Rechnungs_ID", "Adressen_ID" und "Adressen_Typen_Id" ... mit drei Fremdschlüsseln. Solange es genau nur 2 Möglichkeiten gibt, würde ich subjektiv den Ansatz mit den Spalten wählen. Beim geringsten Verdacht auf eine unbekannte Anzahl von Möglichkeiten, würde ich die Zwischentabelle als Ansatz wählen.

Mach dir doch mal ne Zeichnung, ein Böxchen für jede Entität (Kunde, Rechnung, Adresse), dann malst du einfach Linien zwischen die Böxchen, wo beide Dinge ein reales Verhältnis zueinander haben. Und dann fügst du die Kardinalität an jedes Verbindungslinienende an, z.B:

Ein (Kardinalität: 1) Kunde kann viele (Kardinalität: n) Adressen haben
Ein (Kardinalität: 1) Kunde kann viele (Kardinalität: n) Rechnungen haben
Eine Rechnung (1) kann nur an einen (1) Kunden geschickt werden
Eine Rechnung (1) kann an eine oder mehrere (falls das für dich Sinn macht) Adressen geschickt werden, alle Adressen müssen aber zum selben Kunden gehören.**

1:n Beziehungen sind in der Regel "Parent(Vater)-Child(Kind)-Beziehungen" und werden durch einen Fremdschlüssel in der Child(Kind)-Tabelle realisiert.

m:n Beziehungen, im konkreten Fall wäre Rechnung zu Adresse eine solche, werden mit Zwischentabellen realsisiert. ggf sind zusätzliche Beschränkungen oberhalb der referentiellen Integrität von dir zu implementieren um geschäfts-logische Fehler und Inkonsistenzen zu vermeiden

** diese Beschränkung musst du u.U. ausserhalb der Datenbank in deiner Geschäftslogik gewährleisten.

Cheers, Frank

[Chrisi]

Hallo Frank,

danke für deine Antwort :)

m:n Beziehungen, im konkreten Fall wäre Rechnung zu Adresse eine solche, werden mit Zwischentabellen realsisiert.

Das deckt sich mit dem was ich mir mit der Extraspalte in der AdressTabelle (Gruppierung) ausgemalt habe.

Mach dir doch mal ne Zeichnung,

Ich male mir meine DB im Moment mit dem DBDesigner auf - der Umwelt zur Liebe :-)

Macht Spaß hier bei euch,
Danke & Viele Grüße
Chrisi

[EKKi]

Mahlzeit Chrisi,

Macht Spaß hier bei euch,

Finden wir auch - deshalb sind wir so gern bei uns. ;-)

MfG,
EKKi