Adress/Kontakt-Daten vollständig vertikal abbilden?

Bildet jemand von euch eigentlich Adress/Kontakt-Daten vollständig vertikal ab?

Ich frage, weil es mir eigentlich als einzig sinnvolle Methode erscheint, wenn man die Daten extrem flexibel managen und nutzen will, ohne dass Änderungen in einer DB/Tabellenstruktur notwendig werden. Adressdaten sind halt so eine Sache die man immer wieder in Projekten braucht, aber von Projekt zu Projekt durchaus immer etwas andere Daten enthalten.

Wenn man die Daten horizontal in der DB abbildet, hat man ohnehin eigentlich nur so etwas wie VarChar-Spalten unterschiedlicher Größe, die dann in der Regel längst nicht alle in jedem Datensatz genutzt werden. Lediglich Geburtstage fallen mir auf Anhieb ein, die man vernünftigerweise mit Date abbilden würde. Aber ansonsten ist man so halt immer recht star unterwegs.

Bei rein vertikaler Abbildung profitiert man davon, dass man die Daten schön atomar halten kann - eine Strasse und eine Plz können z.B. nur zu einem bestimmten Ort innerhalb eines bestimmten Landes gehören - nur mal so als Beispiel - das lässt sich ja noch viel weiter treiben. Eine Person kann z.B. nur einmal existieren, kann aber z.B. mehrere Wohnsitze haben mit entsprechend unterschiedlichen Anschriften, Telefondaten. Einmal kann eine Person so eine private Anschrift erhalten, einmal kann sie in einem Unternehmen als Ansprechpartner mit entsprechenden Kontakt-Daten versehen sein.

Klaro - der Aufwand für die Datenintegrität zu sorgen ist so ein bisschen höher, aber das macht man nur einmal und man kann das dann halt eigentlich uneingeschränkt weiterverwenden.

Oder spricht doch etwas dagegen? Denk ich zu kurz?

Ich denke, das kommt auf den Verwendungszweck, bzw. deine Stakeholder an.

Hast du z.B. Geschäftskunden, so wirst du damit oftmals nicht weiterkommen, weil die ihre Adressdaten in einer ganz bestimmten Form haben wollen.

Hast du Otto-Normalverbraucher, so geben die Ihre Daten wie Kraut und Rüben ein. Groß und Kleinschreibung ist da noch das kleinste Problem.

Generell also eine Möglichkeit die du beschreibst, nur oftmals wirst du keinen Nutzen erzielen, oder das Aufwand/Nutzen Verhältnis passt halt nicht.

Wg. Geschäftskunden die die Daten in einer bestimmten Form haben wollen - ich sehe wenig Probleme darin, die Daten bei Bedarf in einer gewünschten Form abzubilden - wie die Daten am Ende in der DB gehalten werden, sollte da eigentlich keine Rolle spielen.

Wg. Otto-Normal-Verbraucher - ich sehe da jetzt keinen Unterschied ob der seine Kraut und Rüben Eingaben in der einen oder anderen Datenbank vornimmt. Das User-Interface muss den User bei der Eingabe so oder so so (sososo ) gut wie es nur irgendwie geht unterstützen, damit gewisse Dinge eben atomar abgebildet bleiben. Mit dem heutzutage allgegenwärtigen autosuggest kann man doch schon einigen Dingen entgegenwirken. Ein gewisser "Schwund" wird aber trotz aller Maßnahmen nicht vermeiden lassen - damit muss man wohl irgendwie leben.

Des Pudels Kern ist halt, dass ich sozusagen ein Framework für Adressen haben möchte, dass ich für ein Projekt einfach nur installiere, konfiguriere und dann damit loslegen kann. Evtl. lässt sich ein gewisse Basis auch im Sinne von CoC erstellen sodass weitere Konfigurationen nur für spezielle Anwendungsfälle gebraucht werden.

Ich hab gestern damit begonnen mich mit damit etwas zu beschäftigen und rausgekommen ist erst einmal eine Basis-Tabelle und eine weitere Detail-Tabelle, die verschiedenste Daten eben komplett vertikal hält. Dazu hab ich entsprechende Klassen erstellt, die die Eingabe neuer Datensätze handlen und dafür sorgen, dass es keine doppelten Einträge von Land/Plz/Ort/Strasse gibt, wenn z.B. eine weitere Adresse eingetragen wird, die sich eben genau in der gleichen Strasse befindet. Eine gleichlautende Strasse würde nur eingetragen, wenn sie sich nicht im gleichen Ort befindet usw.

Aber je weiter ich meine Gedanken stricke, um so mehr merke ich, dass selbst die Daten aus der Basistabelle komplett in die Untertabelle hinein aufgedröselt werden sollten, bis am Ende nur noch die 'Detail'-Tabelle übrig bleibt.

Die Klassen die dann Datensätze schreiben, bearbeiten und löschen müssen allerdings schon äusserst Sorgfältig erstellt und ausgiebig getestet werden damit am Ende nicht mal aus Versehen ein Datensalat produziert wird, der sich nicht mehr entwirren lässt.