Übernormalisierung einer MySQL-DB mit Adressdaten

[Matthias Reitinger]

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.

Es gibt mit ZEROFILL und LPAD schon mindestens zwei Methoden, das in MySQL zu erledigen.

Grüße,
Matthias

 

[Stummi]

Meine Meinung:
PLZ und Ortsname sind 1:1, in der hinsicht reichen da 2 Tabellen.

User:
id | vorname | nachname | id_anrede | id_email | telefon | strasse | id_ort | datum
Ort:
id | plz | name

 

[Flo<H>]

Meine Meinung:
PLZ und Ortsname sind 1:1, in der hinsicht reichen da 2 Tabellen.

So nicht ganz richtig
Schau dir beispielsweise mal die Postleitzahlen von München an...

 

[vfl_freak]

So nicht ganz richtig
Schau dir beispielsweise mal die Postleitzahlen von München an...

Moin,

doch, eigentlich schon ... davon ausgehend, dass Stummi meint, dass es zu einer PLZ immer nur genau einen Ortsnamen geben kann !

Etwa so:

Ort:
id | plz   | name
1    80000   München-Ost
2    80001   München-Süd
3    80002   München-West
4    80003   München-Nord

Dann ist über die jeweilige ID schon eine Eindeutigkeit gegeben (auch wenn als NAME jeweils nur 'München' eingegeben wird)

Gruß
Klaus

 

[Flo<H>]

Jein. Ich würde sagen eine PLZ ist eindeutig einem Stadtteil und einem Ort zugeordnet. Aber der Ort ist nicht eindeutig einer PLZ zugeordnet. Das heißt ein Ort kann viele Stadtteile und somit auch viele PLZs haben.

Aber wie spitzfindig man hier ist, ist jedem selbst überlassen. Wobei ich hier abhängig von der Anwendung entscheiden würde. Ist die Adresse nicht so wichtig und es erfolgen nicht viele Adresseingaben könnte eine Tabelle reichen. Ist der Hauptbestandteil der gespeicherten Daten die Adresse (vgl. Adressbuch) würde ich es wahrscheinlich normalisieren.

Hab gestern bei Alternate eine schöne Funktion gesehen, die sich mit normalisierten Tabellen recht einfach lösen lässt: bei Eingabe der PLZ wird diese automatisch geprüft und auch gleich der richtige Ort eingetragen.

mfg flo

 

[vfl_freak]

Hab gestern bei Alternate eine schöne Funktion gesehen, die sich mit normalisierten Tabellen recht einfach lösen lässt: bei Eingabe der PLZ wird diese automatisch geprüft und auch gleich der richtige Ort eingetragen.

Moin,

und ? ? ?
Verrätst Du sie uns
Das klappt natürlich nur, wenn dort auch alle Großkunden- und Postfach-PLZ (etc.) erfasst sind ...

Im übrigen muss natürlich in der externen Tabelle (bspw. über entsprechende NODUP-Keys) sichergestellt sein, dass keine PLZ doppelt vorkommt ... also nicht so etwas :

Ort:
id | plz   | name
1    80000   München-Irgendwo
2    80000   München-Sonstwo

Dies hingehen stellt ja kein Problem dar :

Ort:
id | plz   | name
1    80000   München
2    80005   München
3    80010   München
4    80015   München

sondern bildet einfach nur die Realität ab

Gruß
Klaus

 

[Enumerator]

Hi!

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

Dem kann ich nur zustimmern. Dennoch ein paar Anmerkungen...

davon ausgehend, dass Stummi meint, dass es zu einer PLZ immer nur genau einen Ortsnamen geben kann

Das ist nicht richtig: Es gibt Postleitzahlen, die sich mehrere kleine Orte teilen - nicht nur in Deutschland.
Wobei wir beim nächsten Punkt wären - es ist schon fast unverschämt dem Ausland die Registrierung zu verweigern. Unabhängig davon ob die Seite Deutsch, Englisch oder Farsi ist. Gehen wir mal von Deutsch aus - was ist mit Österreichern, Schweitzern und sonstwo lebenden Deutsch-Sprechenden? In deren Land sieht eine Postleitzahl wahrscheinlich ganz anders aus. Und wo in den Tabellen oben ist eine Länder-ID? Oder zumindest Kürzel nach ISO 3166?

Also bei einer so geringen Anmelde-Quote ist es wirklich egal, wo und wie man die Postleitzahlen ablegt. Im Vordergrund steht doch eigentlich nur, dass man aus Rechts- und/oder Geschäftsgründen die Kontaktdaten der Mitglieder vollständig speichert. Mal davon abgesehen: Wie oft interessiert Euch denn die PLZ in Abfragen? Ich mein, Ihr schreibt doch sicher kein Telefonbuch-Ersatz, hm?

Gruß
Enum

 

[suntrop]

Danke euch für eure Antworten. Ist interessant zu lesen.

Wobei wir beim nächsten Punkt wären - es ist schon fast unverschämt dem Ausland die Registrierung zu verweigern.

Kennst du meine Zielgruppe?

 

[Enumerator]

In Deutschland lebende die einen PC benutzen können, ihren Namen, Anschrift und sogar ihre Postleitzahl kennen? Das alles in Zeiten von Globalisierung und Pandemien von Dummheit? Wie zum Teufel willst Du da in 20 Jahren 3000 Nutzer zusammen kratzen? ;-]

 

[XChris]

PLZ und Ort sind keine 1:1 und auch keine 1:N Beziehung!

Eine PLZ und mehre Orte? Bitteschön:
http://www.plz-postleitzahl.de/land.thüringen/plz-99192.html

Ein Ort mit mehren PLZ? Bitteschön:
http://www.plz-postleitzahl.de/land.thüringen/16263/index.html

Und wenn man richtig sucht, findet man auch eine PLZ, welche zwei Orten zugeordnet ist und jeder dieser Orte auch mehre PLZ hat.

Es ist eine schlechte Idee PLZ und Ort ohne Nachzudenken in eine Tabelle zu stopfen. Wenn ich nur Kundendaten verwalte: Okay. Aber sowie ich eine Auswertung machen muss, über Stadtgebiete und Zusammenhänge in irgendeiner Art, dann mache ich mir schon bei der Implementierung das Leben schwer.

Sondern leider eine n:mBeziehung. Ergo: Eigentlich sogar 3 Tabellen wenn man es wirklich vollständig normalsieren müsste.

Chris