Datum wegen Normalisierung ausgliedern

[Brei]

Hallo,

habe ich einer Tabelle ein Feld mit Datumswert. Jetzt können aber mehrere Datensätze das gleiche Datum haben. Laut 2. Normalform wäre das ein Verstoß. Das Datum auszugliedern ist doch aber eher ein Schmarrn.

Nochwas zur Normalisierung:

Es heißt ja, dass wenn eine Tabelle einen einfachen Primärschlüssel hat (keinen zusammengestetzen) und sie in der 1. NF ist, dann ist erfüllt sie automatisch die 2. NF => WARUM?

[adragon]

Hallo,

habe ich einer Tabelle ein Feld mit Datumswert. Jetzt können aber mehrere Datensätze das gleiche Datum haben. Laut 2. Normalform wäre das ein Verstoß. Das Datum auszugliedern ist doch aber eher ein Schmarrn.

Nochwas zur Normalisierung:

Es heißt ja, dass wenn eine Tabelle einen einfachen Primärschlüssel hat (keinen zusammengestetzen) und sie in der 1. NF ist, dann ist erfüllt sie automatisch die 2. NF => WARUM?

Zu Datumswert... also das ist abhängig vom Datenvolumen (das evt. zur Verfügung steht).. 10 oder 1000 Datensätze welche das gleiche Datum aufweisen können. Bei vielen wäre es bestimmt nicht falsch...

Zu Normalisierung..

1.NF.. wenn es atmor ist

2.NF.. wenn zusätzlich ein Primärschlüssel angegeben wird....

[Ganymed]

Also ein Datum ausgliedern ist absoluter Unsinn.

Normalisierung ist schon richtig und wichtig, allerdings auch irgendwann auch fraglich.

Klassisches Beispiel sind die Postleitzahlen.

Die meisten sind der Meinung (auch ich; damals X-mal in der Berufsschule diskutiert) dass das Trennen von Zahl und Ort unsinnig ist.

In der Theorie müsste man dies machen.

Hier in der Praxis habe ich für jeden Datensatz einen Timestamp hinterlegt. Bei ca. 200 Tabellen ganz schön viel. Ich würde Haarausfall bekommen, wenn ich auch noch für sowas ne extra Tabelle hätte.

Ich würde sagen, lass das Datum zusammen; es verändert nicht wirklich was, wenn du es ausgliedern würdest (dafür gibts auch einfach viel zu viele Möglichkeiten, die deine Kreuztabelle schnell stark aufblähen lassen würden). Außerdem ist es irgendwann SEHR schwer zum warten (je nach Komplexität)

[adragon]

Also ein Datum ausgliedern ist absoluter Unsinn.

Normalisierung ist schon richtig und wichtig, allerdings auch irgendwann auch fraglich.

Klassisches Beispiel sind die Postleitzahlen.

Die meisten sind der Meinung (auch ich; damals X-mal in der Berufsschule diskutiert) dass das Trennen von Zahl und Ort unsinnig ist.

In der Theorie müsste man dies machen.

stimme zu.. ORT und PLZ trennen zuviel aufwand (-> 3 Tabellen)

aber bei einem Datum... wenn er am Tag nehmen wir mal an 1 Millionen Datensätze aufnimmt und die alle das gleiche Datum haben.. würde das mehr Speicherplatz verbrahten als wenn nur der Fremdschlüssel(Integer) für ein Datum mitabgespeichert wird. Es kommt also auf das Datenvolumen (Umfang) bzw den zur Verfügung stehenden Speicherplatz...... wenn diese dinge nicht wichtig sind... würde ich es auch nicht auslagern.....

[Ganymed]

aber bei einem Datum... wenn er am Tag nehmen wir mal an 1 Millionen Datensätze aufnimmt und die alle das gleiche Datum haben.. würde das mehr Speicherplatz verbrahten als wenn nur der Fremdschlüssel(Integer) für ein Datum mitabgespeichert wird. Es kommt also auf das Datenvolumen (Umfang) bzw den zur Verfügung stehenden Speicherplatz...... wenn diese dinge nicht wichtig sind... würde ich es auch nicht auslagern.....

Man sollte es auch Thematisch betrachten; wenn das Datum im Mittelpunkt der Tabelle steht, ja - in Ordnung. Dann ist das Datum mein Such und Kriteriumswerkzeug in der Datenbank und für mich der Schlüssel zum Ziel.

Wenn ich das aber nur z.B. als Registrierungsdatum für einen User habe, dann steht der User und seine Kundennummer im Mittelpunkt und das wäre mein Werkzeug. Da würde ich eine Trennung vom Datensatz her absehen, weil es lediglich eine Zusatzinformation ist (ich kann z.B. Abfragen, wieviele Kunden sich am Tag XY registriert haben).

Ob das Datum jetzt einmal in dem Kundendatensatz steht oder als integer in einer Kreuztabelle ausgelagert wird ist dann letztendlich mehr oder weniger das Gleiche.

Man sollte halt auch sein Arbeitsgebiet im Auge behalten und schauen, was Verwaltungs- und Wartungstechnisch sinnvoll ist.

Ressourcen sollten heute nicht mehr SO das Thema sein.

edit:

Mein Timestamp zeigt an, wer wann welchen Datensatz geändert hat. Das sind auch mehrere 100.000 Datensätze (durchaus mal ne Million) am Tag. Da das aber nur eine Zusatzinformation ist, woher der Satz kommt, würde ich das niemals auslagern.

[perdian]

Das Datum auszugliedern ist eigentlich gar nicht möglich.

Wieso? Es ist schon atomar, und eine ID für ein Datumswert wäre ein vollkomme unnütze Redundanz!

06.05.2005 - wie will ich das denn noch weiter aufsplitten?

Letzten Endes kann man ein Datum auch "nur" wie einen normalen Integer betrachten (und AFAIK läuft das bei vielen Datenbanken intern auch so), in diesem Fall wäre es halt 20050506

Und jetzt muss mir schonmal jemand sagen, wie ich das noch in eine eigene Tabelle ausgliedern will. Klar, theoretisch möglich wäre sowas:

ID    Datum

1     01.01.2005

2     02.01.2005

...

Aber wo ist dann der Witz bei der ganzen Geschichte? Es bringt mir nicht mal Speicherplatzvorteile. Naja, wenn ich nur 10 Tage verwalte, dann kann die ID vielleicht als short und das Datum selbst als int laufen - aber das ist schon sowas von vernachlässigbar, dass ich nichtmal dran denken will

Generell zur Normalisierung, dort ist es wie mit vielen Dingen: Sehr sinnvoll, aber man kann auch alles übertreiben.

[adragon]

Das Datum auszugliedern ist eigentlich gar nicht möglich.

Wieso? Es ist schon atomar, und eine ID für ein Datumswert wäre ein vollkomme unnütze Redundanz!

06.05.2005 - wie will ich das denn noch weiter aufsplitten?

Letzten Endes kann man ein Datum auch "nur" wie einen normalen Integer betrachten (und AFAIK läuft das bei vielen Datenbanken intern auch so), in diesem Fall wäre es halt 20050506

Und jetzt muss mir schonmal jemand sagen, wie ich das noch in eine eigene Tabelle ausgliedern will. Klar, theoretisch möglich wäre sowas:

ID    Datum

1     01.01.2005

2     02.01.2005

...

Aber wo ist dann der Witz bei der ganzen Geschichte? Es bringt mir nicht mal Speicherplatzvorteile. Naja, wenn ich nur 10 Tage verwalte, dann kann die ID vielleicht als short und das Datum selbst als int laufen - aber das ist schon sowas von vernachlässigbar, dass ich nichtmal dran denken will

Generell zur Normalisierung, dort ist es wie mit vielen Dingen: Sehr sinnvoll, aber man kann auch alles übertreiben.

wieso nicht möglich?..wenn es NUR atomar ist erfüllt es nur die 1.NF.. -> 3.NF

vollkomme Redundanz?... und was ist wenn du das Datum nicht auslagerst?..eine ebenso... ich beschreibe hier NICHT die 1.NF..... ich lagere nur ...immer wieder gleich vorkommene Informationen aus es ist kein muss aber es ist auch NICHT FALSCH..(...bisschen übertrieben) ..

wie schon gesagt alles abhänig von der Größe des Systems bzw der Datenbank......

[perdian]

vollkomme Redundanz?... und was ist wenn du das Datum nicht auslagerst?..eine ebenso...

Eben!

Es bringt nichts, da noch weiter normalisieren zu wollen. Es geht einfach nicht. Du bekommst hinterher keine "bessere" Tabellenstruktur raus, sondern im Gegenteil. Ich bekomme nichts als eine weitere bijektive Abbildung ID <-> Datum. Wenn zwei Felder in zwei Datensätzen dengleichen Wert haben, dann heisst das noch lange nicht, dass normalisiert werden muss.

Ich kann auch anfangen Nachnamen zu normalisieren. Müller z.B. soll ja in Deutschland durchaus mehrfach vorkommen - also ab damit, in eine Lastname Tabelle, und vom Kunden nur noch referenzieren. "Vollkommener Quatsch" wird jetzt jemand rufen aber genauso ist das mit dem Datum aus. Nein, das Datum ist sogar noch viel besser dran, bei 200x Müller-Lüdenscheid -> Id 205 spare ich sogar noch was an Speicherplatz.

Und während in Villariba noch normalisiert wird, wird in Villabacho schon das Produkt verkauft

[Brei]

ok, danke.

Sowas habe ich mir schon gedacht (dass das Ganze äußerst fragwürdig ist)

Danke

[perdian]

Sowas habe ich mir schon gedacht (dass das Ganze äußerst fragwürdig ist)

Naja das Konzept an sich ist schon in Ordnung - man muss natürlich immer aufpassen, dass man sich nicht selber zum Sklaven eines solchen Konzeptes machen lässt. Normalisierung ist gut und wichtig, aber genauso wichtig ist es, zu erkennen wo man damit aufhören sollte, bzw. ganz bewusst bestimmte Nachteile in kauf nimmt.

Ich hatte vor ca. einem Jahr solch einen Fall gehabt: Eine Produktdatenbank mit Properties.

Anzahl der Produkte: ca. 50.000

Properties pro Produkt: ca. 100

Ganz logisch, die Properties lagern wir in eine eigene Tabelle aus. So weit, so gut. Aber als dann der erste Import der Produktdaten durchgelaufen war, stellte sich heraus, dass eine Abfrage auf der Datenbank über knapp 5 Millionen Properties Einträge schon im Bereich von 10-20 Sekunden lag. Und das war für den konkreten Einsatzbereich einfach zu viel. Die Daten mussten schnell angezeigt werden, da es eine komfortable Eingabemaske zur schnellen Datenänderung sein sollte. Und was hilft mir die komfortabelste Maske, wenn ich 90% der Zeit mit dem Warten auf die Daten verbringe?

Kurzum, da musste dann halt anti-normalisiert werden. Die Properties wieder mit zurück in die Artikeltabelle und schwups - die Query war runter auf ein paar Millisekunden.

Das Konzept kann also noch so toll sein - wenn es die Erfordernisse aus der Praxis nicht abbilden kann, dann ist es schlicht und ergreifend nicht brauchbar.

[Nachtgeist]

Ich hatte vor ca. einem Jahr solch einen Fall gehabt: Eine Produktdatenbank mit Properties.

Anzahl der Produkte: ca. 50.000

Properties pro Produkt: ca. 100

Ganz logisch, die Properties lagern wir in eine eigene Tabelle aus. So weit, so gut. Aber als dann der erste Import der Produktdaten durchgelaufen war, stellte sich heraus, dass eine Abfrage auf der Datenbank über knapp 5 Millionen Properties Einträge schon im Bereich von 10-20 Sekunden lag.

[...]

Kurzum, da musste dann halt anti-normalisiert werden. Die Properties wieder mit zurück in die Artikeltabelle und schwups - die Query war runter auf ein paar Millisekunden.

Ich wage zu behaupen: Euer Index war kaputt.

[hades]

Ich wage zu behaupen: Euer Index war kaputt.

Oder die DB war nicht optimal angelegt:

- Keine Indezies auf haeufig benoetigte Fremdschluessel

- Zusammengesetzte vs. nicht zusammengesetzte Indezies

[adragon]

Eben!

Es bringt nichts, da noch weiter normalisieren zu wollen. Es geht einfach nicht. Du bekommst hinterher keine "bessere" Tabellenstruktur raus, sondern im Gegenteil. Ich bekomme nichts als eine weitere bijektive Abbildung ID <-> Datum. Wenn zwei Felder in zwei Datensätzen dengleichen Wert haben, dann heisst das noch lange nicht, dass normalisiert werden muss.

Ich kann auch anfangen Nachnamen zu normalisieren. Müller z.B. soll ja in Deutschland durchaus mehrfach vorkommen - also ab damit, in eine Lastname Tabelle, und vom Kunden nur noch referenzieren. "Vollkommener Quatsch" wird jetzt jemand rufen aber genauso ist das mit dem Datum aus. Nein, das Datum ist sogar noch viel besser dran, bei 200x Müller-Lüdenscheid -> Id 205 spare ich sogar noch was an Speicherplatz.

Und während in Villariba noch normalisiert wird, wird in Villabacho schon das Produkt verkauft

so ein käse....

klar kann man vornamen usw auslagern.. aber ist abhänig.. vom projekt.. aber in diesem Fall..(Vornamen und Nachnamen auslagern) zu 99%ig nicht sinnvoll... aber machbar..!!!

und wenn es um schnelligkeit geht...dann ist es besser du lagerst gar nichts aus. .. ist vom zugriff her schneller..

aber jeder wie er will beziehungsweise.. wie die firma will...

[Aiun]

*g* ich weis das ich damit schlafende Hunde wecke,

aber sehr oft ist Normalisierung schlicht Schwachsinn !

Normalisierung will dir oft vorgaukeln das du noch 3-4 Tabellen mehr brauchst, und natürlich 20 Attribute :beagolisc

Suche dir deine Entitäten und überlege dann welche Daten du als Einzelwert brauchst.

Beispiel ist die Adresse: es gibt Programme da ist es nützlich die Adresse in Stadt, Land Fluss *falscher film* PLZ, Stadt, Straße unsw. aufzuteilen und es gibt wieder Programme bei deinen es erheblich besser ist, die gesamte Adresse als 1 Textfeld zu implementieren, alles eine Frage von Aufwand / Nutzen.

Genauso verhält sich das mit Ausgliedern in eine andere Tabelle...

Wenn du also überlegst das Datum auszugliedern, dann gug da nicht von seiten der Normalisierung drauf, sondern von Entity-Relation-Sicht *meine Meinung ^^* Gibt es in der Tabelle mehrere Datensätze die die gleiche Entität beschreiben, aber sonst nur das Datum anders ist ?, dann macht es sinn. Ansonsten ist das Datum ein sinnvolles Feld in der Tabelle.

[mme]

Da kann ich Aiun nur beipflichten. Es kommt auf den Einzelfall an. Auch ein Datum kann sinnvoll ausgelagert werden. Wir haben das auch. Am jeden Monatsanfang gehen eine gute Millionen Datensätze mit dem jeweiligen Datum rein. D.h. 1 Mio mit 01.01.2005, 1 Mio mit 3.2.2005 und 1 Mio mit 02.03.2005 usw.

Ob wir nun Speicherplatz sparen oder nicht war uns egal. Wir haben uns dafür entschieden, weil es vorkommen kann das ein Lauf am falschen Tag gelaufen ist. D.h. die Daten vom 3.2.2005 sollen auf den 2.2.2005 geändert werden. Ich brauch dann nur einen Datensatz ändern und nicht 1 Mio.

Also somit ist eine Aussage wie von Perdi oben einfach nicht richtig das es übertrieben und falsch ist ein Datum auszulagern. Es gibt für alles Anwendungsfälle....

Grüße mme