Seite 1 von 1
mysql: Datentyp SET vs 1:n Normalisierung - Diskussion
Verfasst: 03.02.2007, 17:55
von Airport1
Angenommen ich habe eine Reisedatenbank. Fuer eine Reise muss hierbei auch festgelegt werden welche Laender dabei bereist werden. Nun gibt es ca. 180 Laender (soweit ich weiss.. vielleicht wird ja doch noch eins entdeckt

).
Ich koennte nun die 180 Laender fest als SET vorgeben, also als Menge, z.B. 'Argentinien','Brasilien','Uruguay','Paraguay'... usw.
Beim Eintragen einer Reise koennte man dann z.B. alle 4 o.g. als Laender auswaehlen, oder auch nur 1, 2 oder 3. Oder mehr, bei einer Weltreise sogar alle.
Was spricht fuer die SET Loesung bzw. dagegen?
Immerhin koennte ich auch eine weitere Tabelle anlegen, um eine Normalisierung herbeizufuehren: diese enthaelt die ID der Reise und z.B. eine Landes-ID, nehmen wir an die o.g. Laender haben die Landes-ID 1,2,3,4 und die Reise-ID ist 99 dann stuende in dieser Tabelle:
ReiseID LandesID
99 1
99 2
99 3
99 4
Wie wuerdet ihr dieses "Problem" loesen, und warum wuerdet ihr es entweder mit SET oder aber mit einer Extra-Tabelle loesen? Vor- bzw. Nachteile der beiden Loesungen?
Fuer die Ganz Schlauen ist in der Aufgabe ein offensichtlicher Fehler versteckt, ich sage nur ca. 180

Verfasst:
von
SEO Consulting bei
ABAKUS Internet Marketing Erfahrung seit 2002
- persönliche Betreuung
- individuelle Beratung
- kompetente Umsetzung
Jetzt anfragen:
0511 / 300325-0.
Verfasst: 03.02.2007, 19:28
von nachfrag
hallo airport1,
ich würde die Länder in eine eigene Tabelle auslagern.
Damit bist Du flexibler, wenn Du z.B. Dein Angebot in einer weiteren Sprache anbieten oder zusätzliche Infos zu den Ländern bereitstellen willst.
Ein Schlüssel könnte dann auch der 2- bzw 3 stellige ISO Code (z.B. DE) sein, das ist vielleicht "transparenter" als eine ID?
grüße
Verfasst: 03.02.2007, 19:36
von seobug
180? Es gibt "offizielle" Ländertabellen, die von Behörden usw. genutzt werden.
Gruß seobug
Verfasst: 03.02.2007, 20:59
von net(t)worker
du hast verschiedene Länder und verschiedene Reisen.... jedes land kann von verschiedenen reisen besucht werden... eine Reise kann mehrere Länder enthalten...
hmm...
hier is nix mit 1:n, das ist n:m und wird über eine Tabelle gelöst wie du sie selber schon angesprochen hast...
und du solltest auf jeden Fall mit Tabellen arbeiten, da du mit den Ländern ja auch noch weitere Informationen verknüpfen müsstest, z.B. Welche Papiere zur Einreise nötig sind, welche Impfungen nötig sind etc.... wobei dann z.B. bei den Papieren zur Einreise ggf. auch noch die Staatsbürgerschaft des Reisenden berücksichtigt werden müsste...
Re: mysql: Datentyp SET vs 1:n Normalisierung - Diskussion
Verfasst: 04.02.2007, 22:48
von robo
Airport1 hat geschrieben:Angenommen ich habe eine Reisedatenbank. Fuer eine Reise muss hierbei auch festgelegt werden welche Laender dabei bereist werden. Nun gibt es ca. 180 Laender (soweit ich weiss.. vielleicht wird ja doch noch eins entdeckt

).
Ich koennte nun die 180 Laender fest als SET vorgeben, also als Menge, z.B. 'Argentinien','Brasilien','Uruguay','Paraguay'... usw.
Beim Eintragen einer Reise koennte man dann z.B. alle 4 o.g. als Laender auswaehlen, oder auch nur 1, 2 oder 3. Oder mehr, bei einer Weltreise sogar alle.
Das ist dann aber n:m, nicht 1:n.
Airport1 hat geschrieben:Was spricht fuer die SET Loesung bzw. dagegen?
Gegen die SET-Lösung spricht vor allem, dass diese auf 64 Elemente beschränkt ist.
https://dev.mysql.com/tech-resources/ar ... atype.html
Airport1 hat geschrieben:Immerhin koennte ich auch eine weitere Tabelle anlegen, um eine Normalisierung herbeizufuehren: diese enthaelt die ID der Reise und z.B. eine Landes-ID, nehmen wir an die o.g. Laender haben die Landes-ID 1,2,3,4 und die Reise-ID ist 99 dann stuende in dieser Tabelle:
ReiseID LandesID
99 1
99 2
99 3
99 4
Wie wuerdet ihr dieses "Problem" loesen, und warum wuerdet ihr es entweder mit SET oder aber mit einer Extra-Tabelle loesen? Vor- bzw. Nachteile der beiden Loesungen?
Ich würde es mit einer zusätzlichen Tabelle lösen - nur so hast du eine maximale Flexibilität.
cu, Robo

Verfasst: 05.02.2007, 01:34
von Airport1
robo hat die eine Schwachstelle gefunden, das Limit auf 64 Elemente, da 8 Bytes mit je 8 bit - thumbs up, die Bierkruege hoch
Weiss jemand ob der ISO-Code von Deutschland D oder aber DE ist..
Verfasst: 05.02.2007, 07:12
von mcchaos
Verfasst: 05.02.2007, 12:24
von robo
Verfasst: 05.02.2007, 14:31
von sean
wenn du im SET die Ids der Länder speicherst, kann das u.U. leseoptimierter sein. Je nach Auslastung und Art des Servers. Ich hab projekte wo ich beide varianten einsetze.
Gruß
sean
Verfasst: 05.02.2007, 15:12
von net(t)worker
sean hat geschrieben:wenn du im SET die Ids der Länder speicherst, kann das u.U. leseoptimierter sein. Je nach Auslastung und Art des Servers. Ich hab projekte wo ich beide varianten einsetze.
Gruß
sean
und wie kann er dabei die 64er grenze austricksen?
Verfasst: 05.02.2007, 15:32
von Airport1
Was haltet ihr von dieser Loesung, wieder mal nicht normalisiert

:
1 Tabelle der ISO COdes mit Laendernamen in englisch und deutsch (3 Spalten also, wobei der ISO Code der PK ist)
In die Reisetabelle kommt bei BereisteLaender ein String rein der z.B. enthaelt:
"AR BR UY PY"
Ist zwar nicht "ganz sauber" und schon gar nicht normalisiert, aber das Handling ist doch ein wenig besser bei der Eingabe und Pflege, behaupte ich mal

Verfasst: 05.02.2007, 20:55
von mcchaos
Ja, aber die Perfomance ist übel, wenn Du dann in einem Join mal nach LIKE '%BR%' abfragst
