DB normalisierung

[derocco]

Ich habe mir ein DB Modell skizziert und es schön normalisiert. (ist zwar schon 15 jahr her sein dem ich das mal gelernt habe...)

Nun frage ich mich aber ob es wirklich Sinn macht so. (performance mässig)

Ich habe Grosskunden, Filialen und Endkunden

Auf all diesen Stufen giebt es Strasse, StrassenNO, Zip und Place.

Sauber runter normalisiert würde da ja in den 3 Tabellen nur jeweils die FK zu 4 weiteren Tabellen stehen.

Also hätten wir eine street Table, eine StreetNO table einen Zip Table und eine Place Table.

Das heisst aber wenn ich von einem Endkunden zB. seine Anschrift möcht, dann brauche ich die EndkundenTable und join auf 4 weitere tables.

Performt das?
Wäre es nicht schneller ich habe all diese Info direkt in der Endkunden tabelle?

Ist mir schon klar, dass ich dann wenn ich 3 Kunden habe die an der Wiesenhalde wohnen, nur die Wiesenhalde id verlinke und im Falle eines Typos das nur 1 mal korrigiere etc.
Aber ich erkaufe mir das mit 4 Joins bei der abfrage und mit immer noch einem Select vor dem Insert, wenn ich einen neuen Endkunden anlege.
Dann muss ich ja jedesmal noch prüfen ob ich die Strasse schon kenne, wenn nein insert, wenn ja fetch ID, ebenso bei Zip, place und vor allem Streetno.

 

[Mojo1987]

Machs andersrum.
Erstelle ne Tabelle mit allen Inhalten und Unterscheide via Typ Spalte nach Gross kunde, Endkunde, Filiale etc. Und erstelle ne Tabelle für die möglichen Typen.

Sollte die Möglichkeit bestehen das ein Datensatz alles 3 sein kann brauchst du eben noch ne zwischen Tabelle mit Zuordnungen. Adressen so kleinteilig aufzulösen macht meiner Meinung nach keinen Sinn.

 

[ella_one]

Kannst Du das Datenmodell nach Access überführen und die Übersicht der Beziehungen (Diagramm) hier posten?
Eine Haupttabelle, welche Daten in 1:n Beziehungen zugeordneten Tabellen nachschlägt, könnte hier, wie bereits oben erwähnt, durchaus eine Lösung sein. Doch ohne Kenntnis des derzeitigen Datenmodells sind allfällige Probleme schwerlich ersichtlich.

 

[Yuuri]

Ich habe Grosskunden, Filialen und Endkunden

Und warum hast du dort aufgehört? Kunde = Kunde = Kunde. Also eine Kundentabelle mit ner Unterscheidung welcher Typ der Kunde besitzt. Kann ein Kunde mehrere Typen haben, bringst du dort noch ne Assoziation über ne dritte Tabelle mit ein, wo Kunde und Typ verknüpft werden.

 

[Aduasen]

Performance kommt auch auf die Größe der Tabellen an.
Von was reden wir hier?
Millionen Datensätze?
Die Straßen und die Straßennummern als jeweils getrennte Tabelle zu halten, finde ich sehr fragwürdig.
Auch ZIP und Ort gehören doch zusammen, waum dafür 2 Tabellen bilden?
Für die 5 Fälle, bei denen zur gleichen ZIP zwei Orte gibt ?

 

[Dalek]

Ich würde die Adresse generell nicht so weit normalisieren, das bringt hier nicht wirklich einen Vorteil und Adressen sind durchaus komplizierter als man am Anfang denkt. Die Adressen als ganzes in einer separaten Tabelle kann sinvoll sein, wenn man häufiger die gleiche Adresse hat bzw. wenn Kunden mehrere Adressen haben können oder wenn man den Verlauf der Adressen behalten will. Du musst da aber auch berücksichtigen das sich Adressen ändern, und das man z.B. bei Vorgängen die zu diesem Zeitpunkt angegebene Adresse unveränderlich speichern will. Du willst nicht nachträglich auf Rechnungen die Adresse updaten wenn ein Kunde seine Adresse ändert.

In vernünftigen Datenbanken sind JOINs nicht so langsam, da würde ich erst optimieren wenn ich messbare Probleme habe. Erstmal das Schema vom Konzept her gut machen, man kann immer noch später Denormalisieren wenn man sieht das die Performance problematisch ist.

 

[Enurian]

Adressen so hart zu normalisieren ist ziemlich albern, vor allem vor dem Hintergrund dass das immer gern als Normalisierungsbeispiel hergenommen wird. Das ist nur praktikabel, wenn deine Datenbank tatsächlich alle möglichen Adressen (bzw. Orte, deren Postleitzahlen, Straßen) führt und keinen Freitext zulässt, wie man es aus manchen Websystemen kennt. Das wird besonders interessant, wenn auch internationale Adressen unterstützt werden müssen.
Wenn du dem User freie Hand bei der Eingabe lässt oder gar Daten von irgendwo importieren musst, bringt dir das mehr Ärger als Nutzen. Ich habe schon so einige Applikationsdatenbanken in der Größenordnung 1.000 bis 1.000.000 Adressen von verschiedenen Herstellern gesehen, da war die größte Normalisierung bisher eine Tabelle mit so in etwa Strasse-Postfach-PLZ-Ort-Nation sowie einer Adressart. Diese Adressen können dann verschiedenen Anschriften zugeordnet werden.

 

[ayngush]

Kunden = natürliche Personen & juristische Personen
Lieferanten = juristische Personen & natürliche Personen
Ansprechpartner = natürliche Personen
Partnerunternehmen= juristische Personen
Am Ende sind das alles Personen mit Anschrift(en), Kontakt(en), Anrede, ...
Also eine Personen-Entität und ein Rollenkonzept drüber für 3NF.

Anschriften & Kontaktdaten auf 3NF zu normalisieren hat sich in der Praxis hat nicht so sehr bewährt. Die paar Datensätze sollten dann "doppelt" gepflegt werden, ansonsten bekommt man Probleme bei Korrekturen Beispiel: Pärchen lässt sich scheiden - Frau zieht um, beim Mann wird die "gemeinsame" Anschrift mit geändert usw. Ergebnis: Mist. Also hat eine Person auch immer eine eigene Anschrift und eigene Kontaktdaten - auch wenn dann eine Telefonnummer mal doppelt im System ist. Das ist in der Regel weniger Fehleranfällig als anders herum.

 

[KitKat::new()]

Pärchen lässt sich scheiden - Frau zieht um, beim Mann wird die "gemeinsame" Anschrift mit geändert usw. Ergebnis: Mist. Also hat eine Person auch immer eine eigene Anschrift und eigene Kontaktdaten - auch wenn dann eine Telefonnummer mal doppelt im System ist. Das ist in der Regel weniger Fehleranfällig als anders herum.

Inwiefern ist das ein Problem auf Grund von Normalisierung?
Auch mit Normalisierung kann jede Person eine eigene Anschrift haben.