Adressen in Datenbank speichern

[Bernd (Gast)]

Hallo liebes Forum,

ich plane gerade eine MySQL Datenbank, in der ich Kunden aus dem Inland 
speichern möchte. Für den Anfang würden mir 2 Adressen pro Kunde völlig 
ausreichen, aber mir ist natürlich klar, dass sich Anforderungen ändern 
können und vermutlich auch werden.

Es folgt ein Minimal-Beispiel, wie ich mir das gespeichert in einer 
Datenbank vorstellen könnte:

Tabelle: "adressen"
Spalten:
id
kunde_id
adresstyp_id (int, verweist in Tabelle "adresstypen" z.B. auf "Privat" 
oder "Geschäftlich")
strasse
hausnummer
plz
ort
land

Bezüglich der Standard-Anschrift oder auch primären Adresse bin ich mir 
nicht sicher, ob ich die nun als bool in den Adressen speichern soll, 
oder lieber als Fremdschlüssel in der Kundentabelle...ich tendiere eher 
zur Kundentabelle, da dann weniger Redundanz vorhanden ist. Aber gibt es 
da nicht irgendwelche best practices für das Speichern von relativ 
einfachen Adress-Datensätzen?

Würdet ihr das genauso oder anders machen und warum?

Grüße...Bernd

[MaWin (Gast)]

Bernd schrieb:
> gibt es da nicht irgendwelche best practices für das Speichern von
> relativ einfachen Adress-Datensätzen?

Erst mal sollte man begreifen, dass nicht in jedem Land Adressen gleich 
wie in Deutschland notiert werden.

Nicht jeder Ort hat Strassen, manche Orte mehr als 1 Postleitzahl. Halte 
einfach 5 Adresszeilen plus Land (in Sprache des Absenders bzw. 
französisch) bereit.

Privat und geschäftlich sind unnütz, eher Rechnungsadresse und 
Lieferadresse, da kann sich auch der Name unterscheiden.

[T.roll (Gast)]

Bernd schrieb:
> in der ich Kunden aus dem Inland
> speichern möchte.

MaWin schrieb:
> dass nicht in jedem Land Adressen gleich
> wie in Deutschland notiert werden.

Wenn er nur Inland speichern will, muss er wohl nicht alle 
Adressvarianten der ganzen Welt berücksichtigen.

[Bernd (Gast)]

Hallo MaWin,


MaWin schrieb:
> Erst mal sollte man begreifen, dass nicht in jedem Land Adressen gleich
> wie in Deutschland notiert werden.

Ich werde nur Adressen aus dem Inland speichern.

MaWin schrieb:
> Nicht jeder Ort hat Strassen

Ich bin mir sicher, dass man in so einem Fall einfach den Ort in das 
Straßenfeld eintragen kann und der Brief kommt trotzdem an, da am 
Zustellort eh jeder Briefträger wissen muss, wie der Hase läuft. Für die 
paar Ausnahmen soll man dann Gefahr laufen, bei der Weiterverarbeitung 
der Daten irgendwann das Problem zu haben, dass die importierende 
Software die Eingabe in getrennten Feldern erwartet? Wenn ich das atomar 
speichere, kann ich ja jederzeit die Daten vermengen - andersrum ist das 
ungleich schwieriger.

MaWin schrieb:
> manche Orte mehr als 1 Postleitzahl.

Wo spielt das bei mir eine Rolle? In das Feld kommt doch letztendlich 
nur eine(!) PLZ???

MaWin schrieb:
> Privat und geschäftlich sind unnütz, eher Rechnungsadresse und
> Lieferadresse, da kann sich auch der Name unterscheiden.

Mist, an die Rechnungdadresse hatte ich bislang nicht gedacht! Ich 
arbeite mit Kunden, die entweder privat zu mir kommen oder von ihrer 
Firma im Rahmen einer Art Weiterbildung geschickt wurden. Insofern ist 
das für mich auch in anderen Bereichen der Datenbank wichtig, ob der 
Kundenstatus privat oder geschäftlich ist. Ist nur die Frage, wo man 
diese Information wie abspeichert?

Vielen Dank und viele Grüße
Bernd

[Georg (Gast)]

Bernd schrieb:
> ob ich die nun als bool in den Adressen speichern soll,
> oder lieber als Fremdschlüssel in der Kundentabelle

Nach den akademischen Regeln für Datenbanken müsstest du für alles, was 
mehr als einmal vorkommen kann, eine eigene Tabelle anlegen - also für 
Orte, weil mehrere Kunden am gleichen Ort wohnen können, für 
Bankverbindungen, darunter wiederum für die Banken, für Strassen, weil 
Kunden in der gleichen Strasse wohnen können, aber auch die gleiche 
Strasse in mehreren Orten vorkommt, und und und. Für deine Zwecke bringt 
das aber kaum Vorteile, macht die Sache aber beliebig kompliziert, daher 
mein Rat, lass es. Mach einfach einen Record für Kunden, in dem alles 
drinsteht, was du brauchst. Dann musst du dir auch keine Gedanken 
machen, wenn du einen Kunden löschst, ob du dann auch den Ort, die 
Strasse, das Bankkonto, die Bank usw. löschen kannst.

Ich bin mir sicher, dass deine Festplatte nicht überläuft, nur weil du 
den Eintrag Berlin mehrfach drin hast.

KISS - keep it simple and stupid

Georg

[Ralf D. (doeblitz)]

Bernd schrieb:
> Hallo liebes Forum,
>
> ich plane gerade eine MySQL Datenbank, in der ich Kunden aus dem Inland
> speichern möchte.

Damit hast du wenigstens schon mal ein überschaubares Problemfeld. :-)

[...]
> Tabelle: "adressen"
> Spalten:
> id
> kunde_id
> adresstyp_id (int, verweist in Tabelle "adresstypen" z.B. auf "Privat"
> oder "Geschäftlich")

Du solltest da auch noch ggfls. zwischen Hausanschrift (d.h. mit Strasse 
und Hausnummer), Postfachanschrift, Packstationsadressen (und deren 
Äquivalenten anderer Paketdienste), und Großempfängeranschriften 
unterscheiden.

Das wird spätestens beim Userinterface bzw. der korrekten Ausgabe zur 
Adressierung von Sendungen und bei der Adressprüfung wichtig sein.

> strasse
> hausnummer

Da dann nicht vergessen, dass die Hausnummer auch Buchstaben enthalten 
kann. Und einen Adreßzusatz (Hinterhaus, Etage, Wohnungs-/Zimmernr.) 
nicht vergessen.

Und Mannheim hat Quadrate, bei denen sieht das auch ein wenig anders aus 
(ich habe auch leider schon zuviel Software gesehen, die mit diesen 
Angaben nicht klar kam).

Kleine Orte haben manchmal nur Hausnummern, keine Strassenangabe.

> plz
> ort
> land

Land ist gut - die meisten Leute vergessen die Sondergebiete, die sowohl 
deutsche als auch z.B. schweizer bzw. österreichische Anschriften haben.

> Bezüglich der Standard-Anschrift oder auch primären Adresse bin ich mir
> nicht sicher, ob ich die nun als bool in den Adressen speichern soll,
> oder lieber als Fremdschlüssel in der Kundentabelle...ich tendiere eher
> zur Kundentabelle, da dann weniger Redundanz vorhanden ist.

Yep, foreign key ist da wartungstechnisch viel freundlicher. Bei 
Adressänderungen brauchst du nur die Adresse selbst zu ändern.

> Aber gibt es
> da nicht irgendwelche best practices für das Speichern von relativ
> einfachen Adress-Datensätzen?

Eigentlich gibt es da nur "frequently made mistakes". "Best practice" 
hängt sehr stark von den konkreten Nutzungsanforderungen ab. Ich habe 
z.B. noch Gemeindeschlüssel und Geokoordinaten mit dabei, weil ich das 
für rechtliche Zuordnung (zu welcher Gebietskörperschaft gehört der Ort, 
wg. lokaler Regelungen) oder Kartendarstellung brauchte.

Ralf (diesbezüglich beruflich vorgeschädigt)

[Konrad S. (maybee)]

Bernd schrieb:
> kunde_id
> adresstyp_id (int, verweist in Tabelle "adresstypen" z.B. auf "Privat"
> oder "Geschäftlich")

Das gehört nicht zu einer Adresse. Wie bildest du den Fall ab, wenn 
private und geschäftliche Adresse gleich sind?

[Sheeva P. (sheevaplug)]

Bernd schrieb:
> ich plane gerade eine MySQL Datenbank, in der ich Kunden aus dem Inland
> speichern möchte. Für den Anfang würden mir 2 Adressen pro Kunde völlig
> ausreichen, aber mir ist natürlich klar, dass sich Anforderungen ändern
> können und vermutlich auch werden.

Ist für solche Daten wirklich ein RDBMS notwendig? Die ganzen Features 
wie Schemasicherheit, Transaktionssicherheit, referentielle Integrität, 
Multi-Version Concurrency Control, kurz: alles, was ein RDBMS bietet, 
ist in diesem Fall IMHO völlig überflüssig.

Im Enterprise-Umfeld werden solche Daten deswegen meistens nicht in 
RDBMS, sondern in einem Verzeichnisdienst gespeichert, etwa einem 
LDAP-Server wie OpenLDAP oder Active Directory. Die entsprechende 
Serversoftware ist für Lesezugriffe optimiert, bietet umfssende 
Möglichkeiten zur Strukturierung der Daten und ein feingranuliertes 
Privilegiensystem für den Zugang.

Ich persönlich würde aber vielleicht sogar den Ansatz einer modernen 
NoSQL-Datenbank wählen. Viele sind schemafrei und speichern lediglich 
JSON-Daten, dadurch können damit unterschiedlichste Adreßformate genutzt 
werden. Mein ganz persönlicher Favorit wäre hier Elasticsearch:

- speichert und indexiert JSON-Dokumente, auch verschachtelte
- verfügt über äußerst leistungsfähige Möglichkeiten zur Volltextsuche
- beherrscht die phonetische Suche nach verschiedenen Algorithmen
- bietet eine Fuzzy-Suche mit Levenshtein-Algorithmus
- ist extrem performant, leicht zu installieren und zu betreiben
- hat eine ausdrucksstarke und flexible Such-Syntax
- Speicherung der Objekte, Suchanfragen und -Antworten alle in JSON

Ein Kunde könnte dann so aussehen:

{
  "nachname": "Plug",
  "vorname": "Sheeva",
  "adressen": [
    {
      "adresszeile1": "Dingsstraße 4",
      "adresszeile2": "12345 Bums",
      "flags": ["privat", "geschäftlich"]
    },
    {
      "adresszeile1": "Residence des Fleurs",
      "adresszeile2": "8 Rue de Wattrelos",
      "adresszeile3": "75310 Paris",
      "flags": ["ferienhaus"]
    }
  ],
  "telefonnummern": [
    {
      "nummer": "2345678",
      "flags": ["privat"]
    },
    {
      "nummer": "5678901",
      "flags": ["geschäftlich"]
  ],
  "dokumente": [
    {
      "typ": ["schreiben", "eingang"],
      "datum": "2017-01-01",
      "betreff": "Mäuse im Ferienhaus",
      "inhalt": "Die Mäuseplage wird immer schlimmer."
    },
    {
      "typ": ["schreiben", "ausgang"],
      "datum": "2017-01-02",
      "betreff": "Mäuse im Ferienhaus",
      "inhalt": "Versuchen Sie es mit Mausefallen."
    },
    {
      "typ": ["rechnung", "ausgang"],
      "datum": "2017-01-03",
      "betreff": "Mäuse im Ferienhaus",
      "positionen": [
        {
          "nummer": 1,
          "titel": "Ratschlag erteilt",
          "netto": 10.00,
          "steuersatz": 19.0
        }
      ]
    }
  ]
}

...you get the idea -- wobei ich die Schreiben und Rechnungen vermutlich 
eher als Relationen modellieren würde, egal. Am Ende liegen dann alle, 
und zwar wirklich alle Kundendaten hübsch zusammen, können nach 
verschiedenen Kriterien und in Bruchteilen von Sekunden durchsucht 
werden, und wenn die Firma wächst und dem Server die Luft ausgeht, 
klemmt man einfach weitere daneben und konfiguriert daraus einen 
hochverfügbaren Cluster. Der größte Nachteil ist, daß Elasticsearch eine 
sehr umfangreiche Software ist und es einigen Einarbeitungsaufwandes 
bedarf, um seine volle Leistungsfähigkeit ausnutzen zu können. Ein 
erstes Setup ist hingegen ausgesprochen einfach und auch von Laien 
problemlos zu machen.

[J. F. (Firma: Père Lachaise) (rect)]

Ich gehe auch klar mit json Dateien. Die sind sehr einfach zu handeln 
und erfüllen genau deinen Zweck. Im gleichen Zuge hab ich mich an das 
Thema der doppelten Einträge erinnert:

https://stackoverflow.com/questions/37568/find-duplicate-addresses-in-database-stop-users-entering-them-early

Vielleicht noch ein Anstoß für dich.

[Sheeva P. (sheevaplug)]

J. F. schrieb:
> Ich gehe auch klar mit json Dateien. Die sind sehr einfach zu handeln
> und erfüllen genau deinen Zweck. Im gleichen Zuge hab ich mich an das
> Thema der doppelten Einträge erinnert:
>
> 
https://stackoverflow.com/questions/37568/find-duplicate-addresses-in-database-stop-users-entering-them-early
>
> Vielleicht noch ein Anstoß für dich.

Im Zusammenhang mit Deinem Hinweis auf Adreß-Duplikate sei vielleicht 
noch darauf hingewiesen, daß jeder von uns wahrscheinlich täglich 
Elasticsearch benutzt: damit werden nämlich die Vorschläge bei der 
Eingabe im Suchfeld der Wikipedia erzeugt. So etwas kann man natürlich 
auch für eine Adreßeingabe abwandeln: sobald jemand "Quell" eingibt, 
kann das Eingabefeld gleich die Möglichkeiten "Quellenstraße" und "Am 
Quellwasser" anbieten. Das erspart Tipparbeit, vermeidet unschöne 
Fehler, und vorhandene Fehler können durch diese Vorschläge relativ 
schnell auffallen und korrigiert werden.

[Pandur S. (jetztnicht)]

Felder :

Titel (Hr, Frau, Dr, Prof, General, Hochwuerden..) als Varchar[16]
Vorname             als Varchar[32]
Nachname            als Varchar[32]
Firma               als Varchar[32]
Abteilung           als Varchar[32]
zusaetzliche Linie  als Varchar[32]
Strasse             als Varchar[32]
PLZ                 als Varchar[16]
Ort                 als Varchar[32]
Provinz             als Varchar[32]
Land                als Varchar[32]

Vergiss die nur-Inland Adressen. Es geht zu schnell bis du auch Ausland 
Adressen hast.

Wichtig bei Suchen in der Tabelle :

 if gross(Eingabe) == gross(Tabelle)
 es gibt Leute, die schreiben nur Grossbuchstaben

 if gross(Eingabe Name) == gross(Tabelle Name) oder
    gross(Eingabe Name) == gross(Tabelle Vorname)
 if gross(Eingabe Vorname) == gross(Tabelle Vorname) oder
    gross(Eingabe Vorname) == gross(Tabelle Name)
 Bei manchen Eintraegen koennen die beiden vertauscht sein.

Falls gewuenscht kann ich Beispiele liefern.

[Cyblord -. (Gast)]

Bezüglich Adressen (das wohl mit eins der ekelhaftesten Themen bzgl. 
Verarbeitung schlechthin):

https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/

(old but gold)

Aus Entwicklersicht finde ich daher den Ansatz von what3words ganz nett 
aber verbesserungswürdig :-)

https://en.wikipedia.org/wiki/What3words

[Michael B. (laberkopp)]

Sapperlot W. schrieb:
> Vorname             als Varchar[32]
> Nachname            als Varchar[32]
> Firma               als Varchar[32]
> Abteilung           als Varchar[32]
> zusaetzliche Linie  als Varchar[32]
> Strasse             als Varchar[32]
> PLZ                 als Varchar[16]
> Ort                 als Varchar[32]
> Provinz             als Varchar[32]
> Land                als Varchar[32]

Typische Pippi Langstrumpf Datenbank "Ich mach mir die Welt wie sie mir 
gefällt". Bitte lasst solche Deppen nicht in die Softwareentwicklung.

Es gibt genpügend Leute, deren Adressangaben nicht in diese Feldbreiten 
passen.

[Pandur S. (jetztnicht)]

> Es gibt genpügend Leute, deren Adressangaben nicht in diese Feldbreiten
passen.

Ok, welche Feldbreiten dann ? Eigentlich waere ein Text-feld fuer alles 
am Stueck eh passender.

Dann geht eine Anschrift mit "Sehr geerter Dr Bla Blub" nicht mehr.

[Der Andere (Gast)]

Sapperlot W. schrieb:
> Ok, welche Feldbreiten dann

Ich sag nur: Hadschi Halef Omar Ben Hadschi Abul Abbas Ibn Hadschi ...
oder 
https://de.wikipedia.org/wiki/Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch

[Manfred M. (bittbeisser)]

> Nicht jeder Ort hat Strassen, ...
Ein solcher Ort ist z.B. Baltrum
https://de.wikipedia.org/wiki/Baltrum#Inselverkehr

> Auf Baltrum gibt es keine offiziellen Straßennamen, sondern lediglich
> Hausnummern, ...
Nur so zur Info.

[Sheeva P. (sheevaplug)]

Michael B. schrieb:
> Sapperlot W. schrieb:
>> Vorname             als Varchar[32]
>> Nachname            als Varchar[32]
>> Firma               als Varchar[32]
>> Abteilung           als Varchar[32]
>> zusaetzliche Linie  als Varchar[32]
>> Strasse             als Varchar[32]
>> PLZ                 als Varchar[16]
>> Ort                 als Varchar[32]
>> Provinz             als Varchar[32]
>> Land                als Varchar[32]
>
> Typische Pippi Langstrumpf Datenbank "Ich mach mir die Welt wie sie mir
> gefällt". Bitte lasst solche Deppen nicht in die Softwareentwicklung.
>
> Es gibt genpügend Leute, deren Adressangaben nicht in diese Feldbreiten
> passen.

Zum Beispiel Karl-Theodor Maria Nikolaus Johann Jacob Philipp Franz 
Joseph Sylvester Buhl-Freiherr von und zu Guttenberg...

Aber die Feldbreiten und sogar das Datenmodell sind dabei nicht einmal 
das wesentliche Problem. Das Problem ist, was Donald Knuth schon 1973 
als Kern der ganzen Problematik erkannt hat: "premature optimization is 
the root of all evil". In der heutigen Zeit, in der volatiler und 
persistenter Speicher nur popelige Centbeträge kosten, ist es total 
bescheuert, schon an solchen Stellen am Speicher zu sparen.

Ein sekundäres Problem ergibt sich zusätzlich daraus, daß MySQL nur ein 
SQL-ähnliches Festplatteninterface ist (Joe Celko). Kurz gesagt: solange 
MySQL nicht in einem seiner STRICT-Modus betrieben wird, kürzt es Werte, 
die nicht in die vorgesehenen Spalten passen, stumpf ein und verwirft 
den übrigen Teil. Aus Karl-Theodor wird, wenn er in eine 
VARCHAR(32)-Spalte eingetragen wird, ein "Karl-Theodor Maria Nikolaus 
Joha". Eine (angeblich) Datenbank, die Daten ohne Fehlermeldung einfach 
wegwirft? Soetwas ist mit "Scheiße" noch sehr wohlwollend beschrieben.

Wer eine leistungsfähige, hochperformante, stabile, standardkompatible 
OpenSource-Datenbank haben will, nimmt PostgreSQL. Das ist ein bisschen 
spröde, ähnlich wie Solaris oder *BSD im Vergleich zu Linux, aber dafür 
unterstützt PostgreSQL wenigstens ältere SQL-Standards korrekt, ist bei 
größeren Datenmengen wesentlich performanter, und besitzt eine erheblich 
umfangreichere, stabile Funktionalität als MySQL und als die meisten der 
kommerziellen Wettbewerber.

Und wer einen schnellen Datenverwalter sucht, der horizontal skalierbar, 
replizierbar, sharding- und cluteringfähig ist, der greift eventuell zu 
PostgreSQL-XL -- oder lieber zu einer NoSQL-Datenbank wie Elasticsearch, 
Apache Solr, MongoDB oder CouchDB.

[Michael U. (amiga)]

Hallo,

Bernd schrieb:
> Ich
> arbeite mit Kunden, die entweder privat zu mir kommen oder von ihrer
> Firma im Rahmen einer Art Weiterbildung geschickt wurden. Insofern ist
> das für mich auch in anderen Bereichen der Datenbank wichtig, ob der
> Kundenstatus privat oder geschäftlich ist. Ist nur die Frage, wo man
> diese Information wie abspeichert?

nicht der Kunde ist privat oder geschäftlich sondern der Auftrag...

Adresen selbst können durchuas privat oder geschäftlich sein, der Kunde 
wohnt dort und seine Firma ist woanders. Das dient aber nur z.B. einer 
Auswahl im Auftrag. Bei einem Privat-Auftrag werden die Privat-Adressen 
zuerst und die anderen darunert, bei einem Firmanauftrag andersrum.
Verringert das Risiko, daß man dem Kunden die Lieferung mit der Palette 
Dildos zur Privatadresse schickt...

Gruß aus Berlin
Michael

[Frank E. (Firma: Q3) (qualidat)]

Eine gute und moderne Alternative zu MySQL ist MariaDB vom gleichen 
Entwickler. Und ja, für einfach strukturierte Daten, wie Adressen, ist 
eine SQL-gesteuerte relationale Datenbank nicht die schlechteste Idee.

Will man keinen haarsträubenden Pfusch verfassen, so sollte man sich 
mindestens mal mit den Normalformen 1-3 befassen.

Man möge auch bedenken, was mal mit den Adressen passieren soll - deren 
Speicherung ist doch bestimmt kein Selbstzweck. Jedes Versand- oder 
Frankierprogramm, jede Faktura benötigt klar geliederte Daten.

Und wenn ein Dorf keine Straßennamen hat, dann setzt man einfach 
"Dorfstraße" ein, kommt immer an.

Adressverwaltung kann auch durchaus kompliziert sein. Wir nutzen in 
unserer Firma z.B. ein selbstgeschriebenes ERP-System und haben echt 2 
Jahre gekämpft, bis das nach unseren Ansprüchen funktioniert. Wir haben 
z.B. Adressen als Unterkriterium zu einem "Unternehmen", denn wir haben 
Adressen von Leuten, die bestellen und mit denen wir zum Auftrag 
inhaltlich kommunizieren. Dann wiederum andere Andressen zum selben 
Auftrag, wo die Produkte hin gesandt werden. Es kommen noch getrennte 
Rechnungsadressen dazu und der Gipfel waren die Aressen von 
Buchhaltungs-Services (durchaus auch den gleichen für mehere 
verschiedene Auftraggeber), wo die Rechnungen zwar postalisch oder per 
Mail hingehen - die aber nicht die Rechnungsempfänger in 
finanztechnischer Sicht sind. War 'ne harte Nummer ...