Übernormalisierung einer MySQL-DB mit Adressdaten

[suntrop]

Hallo,
ich hatte heute mit meinem Programmierer darüber diskutiert, ob in einer Adressdatenbank die PLZ der Mitglieder unbedingt in eine extra Tabelle ausgelagert werden müssen.

Er meint, zwecks Vermeidung von Redundanzen, aus Speicherplatzgründen und wegen besserer Performance die PLZ in eine eigene Tabelle zu schieben.

Ich sehe das etwas anders. PLZ Redundanzen rauben mir nicht den Schlaf - sind ja auch nicht per se böse. Speicherplatz haben wir ausreichend (wir speichern nicht auf Diskette ). Was die Performance angeht … hmm da habe ich zu wenig Erfahrung. Kann mir jedoch Vorstellen, dass bei 300 bis (irgendwann im Jahr 2030) vielleicht mal 3000 Mitgliedern das nicht wirklich ins Gewicht fällt.

So in etwa sehen die Tabellen aus.

User:
id | vorname | nachname | id_anrede | id_email | telefon | strasse | id_plz | id_ort | datum
PLZ:
id | plz | id_ort
Ort:
id | ort

Mir geht es um eine dritte Meinung. Ich lasse mich gerne eines besseren belehren, falls ich falsch liege.

Würde mich über eine paar Antworten freuen.

 

[Yaslaw]

die PLZ ist relativ klein und man kann sie als Zahl deklarieren. Jeder Join zwieschen Tabellen verbraucht ebenfalls Performance.

Ich persönlich würde die PLZ und den Ort nicht normalisieren, gerade weil bei 3000 Einträgen die wahrscheinlichkeit, dass 2000 Orte gespeichert werdn gross ist.

 

[suntrop]

yaslaw, danke für deine Antwort. Das mit dem Join war mir gar nicht klar. Dachte das kostet nichts

die PLZ ist relativ klein und man kann sie als Zahl deklarieren.

PLZ war vorher als Zahl deklariert, dann wurde aber bei den mit Null beginnenden PLZ die Null vorne weggeschnitten.
Wie machst du das, dass die Null beibehalten wird?

 

[Yaslaw]

Hm.. MySQL bietet nix sinnvolles um eine Zahl als formatierten String auszugeben (oder mir ist niy bekannt).
Also als VARCHAR speichern oder im PHP formatieren.

Grundsätzlich braucht jedes JOIN Performance, weil er ja zu jedem Datensatz bei jeder Bafrage die dazugehörigen Informationen zuordnen muss. Je nach Index kann das schneller oder langsamer sein.

Grundsätzlich handhabe ich das mit der Normalisierung so:
- Alle Felder die ich mit einem DropDown meinem Datensatz zuweisen will -> Normalisieren
- Alle Inhalte die mehr als selten über mehrere Datensätze geändert werden müssen -> Normalisieren

Also, PLZ und Ort wechslen alle 50 Jahre ev. einmal, aber nicht dauernd. Ich persönlich mache auf diese Felder auch keine Dropdowns -> ergo normalisiere ich beide nicht.

Aber eine allgemeingültie Lösung gibt es nicht.

Hier noch ienige Dinge zu Performance:
- Jede Funktion die auf ein Feld im SQL ausgeübt werden muss, ist schlecht für die Performance (also CAST, CONNCAT etc)
- bei vielen Daten mit Vernknüpfungen stehts die Daten eingrenzen und dann verknüpfen
- Indexe auf alle Felder legen die auf irgend eine weise durchsucht werden (als auch auf PLZ und Ort, da man sicher danach suchen will)

 

[XChris]

Ich würde sie normalisieren! Nicht aus Prinzip, sondern weil es Sinn macht.

Denn viele Orte haben mehre PLZ. Viel Spass wenn sich da mal was ändert.

Ein weitere Grund: Man weiß nie was kommt ;-) Ich kenne Deine Anwendung nicht. Aber vielleicht benötigst Du irgendwann auch die Zuordnung zum amtlichen Gemeindeschlüssel oder ein Geotacking. Macht sich mit normalsierten Tabellen sehr viel besser.

Die Perfromanze-Aussage von yaslaw ist so nicht ganz richtig. Der Performanzeverlust dürfte bei Abfragen kaum messbar sein. Aber er wird deutlich werden, wenn du konkurrierende schreibende Zugriffe auf den selben Ort MIT der selben PLZ auf einer Tabelle hast. Wenn da ne Sperre auf dem Tupel ist, merkst Du das bei EINER Tabelle sehr viel eher als bei zwei Tabellen.


Die einfachere Lösung ist nur auf den ersten Blick alles in eine Tabelle zu stopfen.

Chris

 

[vfl_freak]

Moin,

ich denke, dass in beiden Antworten ein Körnchen Wahrheit steckt, würde aber grundsätzlich auch eher der Argumentation von Chris folgen!

Wenn man sich mal den Wikipedia-Beitrag zur Normalisierung anschaut ( http://de.wikipedia.org/wiki/Normalisierung_(Datenbank) ), dann wird gleich zu Beginn am Beispiel "Adressdaten" deutlich gemacht, warum es Sinn macht, Ort und PLZ raus zunormalisieren !

Bei 300 (oder 3000) DS spielen Dinge wie Speicherplatz (mithin Redundanzen) und Performance IMHO sicher eher eine untergeordnete Rolle!

Viel wichtiger finde ich die Vermeidung von Anomalien (bspw. durch sich widersprechende Daten), weil dies (wie dort geschildert) die Wartung einer Datenbank und die Wahrung der Konsistenz der Daten erschwert!

Ich erfahre das hier leidvoll jeden Tag in der Firma, wo durch unseren Chef vielfach derartige Dinge mit Füßen getreten werden. Da ist dann bei großen DB's das Chaos vorprogrammiert !

Gruß
Klaus

 

[suntrop]

Denn viele Orte haben mehre PLZ. Viel Spass wenn sich da mal was ändert.

Darin sehe ich keinen Widerspruch zur "Ein-Tabellen-Lösung". Es kann doch User 1 Berlin-Mitte 10115 und ein anderer Berlin 10115 und wieder ein anderer Berlin 10179 notiert haben.

Was meinst du mit "... wenn sich da mal was ändert."? Es ziehen doch nicht alle User von Berlin nach München (viel zu teuer da).

Das Beispiel von Wikipedia stimmt zu wenig mit unserer DB überein (könnt ihr natürlich nicht wissen ). Aber jedes Mitglied ist nur einmal drin und hat keine Aufträge, Produkte oder ähnliches.

Eines ist mir gestern noch eingefallen. Habe ich vorher nicht bedacht. Ich denke ich würde auch auf eine extra Tabelle ausweichen, wenn ich gekaufte Orte samt PLZ hätte. Aber diese Daten kommen von den Usern selbst und wenn die etwas falsch machen, dann wirkt sich das auf andere aus. Das finde ich fatal.


Grüße
- suntrop

 

[vfl_freak]

Darin sehe ich keinen Widerspruch zur "Ein-Tabellen-Lösung". Es kann doch User 1 Berlin-Mitte 10115 und ein anderer Berlin 10115 und wieder ein anderer Berlin 10179 notiert haben.

Das hängt sicher auch ein bißchen davon ab, was mit den Daten geschehen soll!
Was ist denn in Deinem Beispiel nun '10115'? 'Berlin' oder 'Berlin-Mitte' oder 'egal'

Was meinst du mit "... wenn sich da mal was ändert."?

Na, ich würde mal sagen: neue Regierung ... neu Ideen

Das Beispiel von Wikipedia stimmt zu wenig mit unserer DB überein (könnt ihr natürlich nicht wissen ). Aber jedes Mitglied ist nur einmal drin und hat keine Aufträge, Produkte oder ähnliches.

Es sollte auch nur einmal drin - es sei denn, man kann sich bspw. mit unterschiedlichen Adressen anmelden !

Eines ist mir gestern noch eingefallen. Habe ich vorher nicht bedacht. Ich denke ich würde auch auf eine extra Tabelle ausweichen, wenn ich gekaufte Orte samt PLZ hätte. Aber diese Daten kommen von den Usern selbst und wenn die etwas falsch machen, dann wirkt sich das auf andere aus. Das finde ich fatal.

Aha, Du kaufst Orte
Interessant wie teuer sind die denn ? ?

Im Ernst, bspw. kann man in der Stammdatentabelle ein Verzeichnis von PLZ und Ort hinterlegen und dann bei der Eingabe einer PLZ gleich den Ort vorblenden oder auch nur beide Eingabe auf Konsistenz prüfen.
Andernfalls würdest Du ja auch Eingaben wie
10115 Berlin-Süd
oder
55555 Berlin
zulassen

Gruß
Klaus

 

[suntrop]

Was ist denn in Deinem Beispiel nun '10115'? 'Berlin' oder 'Berlin-Mitte' oder 'egal'

egal, solange es nicht falsch ist (10115 Köln wäre z.B. falsch und 50500 Berlin auch).

Aha, Du kaufst Orte
Interessant wie teuer sind die denn ? ?

Nein, ich sagte ja wenn ich sie gekauft hätte. Aber Wowereit war nicht mal zu Gesprächen bereit – glaubt man sowas.

Andernfalls würdest Du ja auch Eingaben wie
10115 Berlin-Süd
oder
55555 Berlin
zulassen

Das ist leider so Weil ich die User-Eingaben heranziehen muss, da keine vorher vorhanden sind.

 

[XChris]

Darin sehe ich keinen Widerspruch zur "Ein-Tabellen-Lösung". Es kann doch User 1 Berlin-Mitte 10115 und ein anderer Berlin 10115 und wieder ein anderer Berlin 10179 notiert haben.

Was meinst du mit "... wenn sich da mal was ändert."? Es ziehen doch nicht alle User von Berlin nach München (viel zu teuer da).

Was könnte sich ändern ... ? Die PLZ selbst!

Das kommt hin und wieder vor. Es kann auch passieren, dass Du EINE Strasse mit mehren PLZ hast. Beispiel Landstrassen. PLZ Änderungen sind häufiger als man denkt.
Ich kenne wie gesagt Deine Anwendung nicht. Aber wenn Du jemals PLZ Kataloge bekommst und deine Daten mit diesen Abgleichen musst ... ich will da keine einzige Tabelle haben. Klar kann man das auch mit SELFJOINS machen. Aber wenn ich es mir ersparen kann, dann mache ich das.

Chris