mysql: Datentyp SET vs 1:n Normalisierung - Diskussion

Beitrag von **Airport1** » 03.02.2007, 17:55

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

von **Anzeige von ABAKUS** »

SEO Consulting bei ABAKUS Internet Marketing
Erfahrung seit 2002

persönliche Betreuung
individuelle Beratung
kompetente Umsetzung

Jetzt anfragen: 0511 / 300325-0.

Beitrag von **nachfrag** » 03.02.2007, 19:28

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

Beitrag von **seobug** » 03.02.2007, 19:36

180? Es gibt "offizielle" Ländertabellen, die von Behörden usw. genutzt werden.

Gruß seobug

Beitrag von **Anonymous** » 03.02.2007, 20:59

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...

Beitrag von **robo** » 04.02.2007, 22:48

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

Beitrag von **Airport1** » 05.02.2007, 01:34

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..

Beitrag von **mcchaos** » 05.02.2007, 07:12

https://www.iso.org/iso/en/prods-servic ... n1.html#gk

Beitrag von **robo** » 05.02.2007, 12:24

https://de.wikipedia.org/wiki/ISO_3166
https://de.wikipedia.org/wiki/ISO-3166-1-Kodierliste

cu, Robo

Beitrag von **sean** » 05.02.2007, 14:31

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

Beitrag von **Anonymous** » 05.02.2007, 15:12

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?

Beitrag von **Airport1** » 05.02.2007, 15:32

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

Beitrag von **mcchaos** » 05.02.2007, 20:55

Ja, aber die Perfomance ist übel, wenn Du dann in einem Join mal nach LIKE '%BR%' abfragst