Wie weit soll man atomisieren

[GlassOne]

Hallo,

atomisieren kann man ja so lange betreiben, bis es nicht mehr sinvoll erscheint.
Ja aber das meist ist das ein Problem zu erkennen wann es soweit ist.
Im Buch habe ich gelesen, das es 1:1 Verbindungen nur selten zur Anwendung kommen, da diese Informationen gleich in eine Tabelle gesteckt werden.

Ich beschäftige mich derzeit mit der Frage, ob man zu einerm Profil einer Person wirklich alles zerlegen soll?
Personendaten (Vorname, Nachname, Geburtsdatum)
Kommunikationen (Telefon, Email)
Adressen (Strasse, PLZ, Ort, Land, Bundeslanf, LGrad, BGrad)
Koerperdaten (Geschlecht, Groesse)

Das Ziel ist ja möglichst Effizient und vor allem platzsparend zu Designen.
Eine Auslagerung in weitere Tabellen wäre nur sinvoll, wenn diese weiterverwendet werden können um Duplikate aus zu schliessen. Gruppierungen lassen sich sehr schön erkennen und auch aus lagern, ist nur die Frage ob es dann wirklich ein gute Datenbankdesign ist?

Die Überlegung die Kommunikation aus zu lagern wäre machbar, aber die Frage wie hoch die Warscheinlichkeit ist, das eine andere Person die gleiche Teleonnummer oder emailadresse hat? Dazu müsste diese Mitglied der Familie sein. Das gleiche Würde für die Adresse gelten. Die Körperdaten wären von Geschlecht, Gröse usw auch wieder so spezielle, das es sich nicht lohnen würde dies aus zu lagern!

Was man eher auslagern könnte, wäre Ort, Bundesland und Land?

Was haltet Ihr von den Überlgungen.
Danke
GO

 

[Dukel]

Ein Anhaltspunkt ist die Normalisierung. Dort werden einige Regeln definiert, die man umsetzen oder ignorieren kann.
Es geht aber nicht nur um das platzsparende Design.

Wenn du Personendaten mit Kommunikationsdaten in einer Tabelle speicherst bist du auf ein Kommunikationsmittel beschränkt oder hast hässliche Workarounds (eMail1, eMail2, eMail3).

 

[Walter]

hässliche Workarounds (eMail1, eMail2, eMail3)

Und ganz typisch taucht dann nach einiger Zeit die Notwendigkeit auf, noch eine vierte Email speichern zu können. In der Datenbank und der Erfassungsmaske ist die vierte Email ja rasch dazu gemurkst, aber spätestens wenn Du dann dutzende Programme umschreiben musst merkt man, dass man einen grundlegenden Designfehler begangen hat und das am besten von Anfang an in eine Tabelle gesteckt hätte.

 

[GlassOne]

Danke, ich werde versuche, mich an die Normalformen zu orientieren.

Auch würde ich gerne wissen, wie im allgemeinen die Tabellen so aussehen!
In Java oder PHP programmiere ich Objektorientiert und benutze meist Variablennamen wie:
personVorname, personNachname, ...
Würde es ausreichen folgende Tabelle zu erstellen?
Personen (ID, Vorname, Nachname, ....)
Oder sollte ich mich an die Variablennamen aus der Programmierung orientieren wie
Personen (personID, personVorname, personNachname, ...)

Danke

 

[ukulele]

Personen (ID, Vorname, Nachname, ....)
reicht völlig. Du kannst in deinen Abfragen sauber arbeiten und immer den vollen Spaltentitel ausschreiben, also z.B.

SELECT Personen.Vorname FROM Personen

oder

SELECT p.Vorname FROM Personen p

So wirst das immer recht übersichtlich und einheitlich sein.

Auf Platzsparend würde ich gar nicht soviel Wert legen, eher auf schlanke Querys. PLZ Ort würde ich z.B. immer in der Adressen-Tabelle lassen und die raus normalisieren.

In deinen Beispiel würde ich Personendaten und Körperdaten grundsätzlich eher in einer Tabelle halten (Natürlich kann ein Nachname-Wechsel hier nicht schön dokumentiert werden). Kontaktdaten wie Adresse und Kommunikation in eine 1:n Beziehung auslagern. Dann kann natürlich eine Telefonnummer doppelt vorkommen, das würde ich dann einfach so hinnehmen.