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
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.
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.
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
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
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)
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?
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:
1
{
2
"nachname": "Plug",
3
"vorname": "Sheeva",
4
"adressen": [
5
{
6
"adresszeile1": "Dingsstraße 4",
7
"adresszeile2": "12345 Bums",
8
"flags": ["privat", "geschäftlich"]
9
},
10
{
11
"adresszeile1": "Residence des Fleurs",
12
"adresszeile2": "8 Rue de Wattrelos",
13
"adresszeile3": "75310 Paris",
14
"flags": ["ferienhaus"]
15
}
16
],
17
"telefonnummern": [
18
{
19
"nummer": "2345678",
20
"flags": ["privat"]
21
},
22
{
23
"nummer": "5678901",
24
"flags": ["geschäftlich"]
25
],
26
"dokumente": [
27
{
28
"typ": ["schreiben", "eingang"],
29
"datum": "2017-01-01",
30
"betreff": "Mäuse im Ferienhaus",
31
"inhalt": "Die Mäuseplage wird immer schlimmer."
32
},
33
{
34
"typ": ["schreiben", "ausgang"],
35
"datum": "2017-01-02",
36
"betreff": "Mäuse im Ferienhaus",
37
"inhalt": "Versuchen Sie es mit Mausefallen."
38
},
39
{
40
"typ": ["rechnung", "ausgang"],
41
"datum": "2017-01-03",
42
"betreff": "Mäuse im Ferienhaus",
43
"positionen": [
44
{
45
"nummer": 1,
46
"titel": "Ratschlag erteilt",
47
"netto": 10.00,
48
"steuersatz": 19.0
49
}
50
]
51
}
52
]
53
}
...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. 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.
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.
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.
> 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.
> 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.
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.
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
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 ...
