Datenbankdesign - Zeitangabe als Eigenschaft mitnutzen?

[BLUESCREEN3D]

Angenommen ich habe in einer Datenbank eine Tabelle mit irgendwelchen Einträgen.
Jeder dieser Einträge ist entweder authorisiert oder noch nicht authorisiert.
In einer Spalte der Tabelle wird der Zeitpunkt der Authorisierung gespeichert.

Ist es besseres Datenbankdesign, eine zusätzliche Spalte "authorisiert" zu erstellen, die true/false enthält,
oder sollte man die schon vorhandene Spalte, die den Authorisierungszeitpunkt enthält, mitbenutzen und sobald diese den Wert 0 hat, davon ausgehen, dass der Eintrag noch nicht authorisiert ist?

[quinte17]

eine zusätzliche spalte braucht mehr platz..
ob du diese information brauchst, wenn das datumsfeld NULL ist? glaub ich nicht.
index auf das datumsfeld und gut genug sollte es sein.
wenn du allerdings die authorisierung mal deaktivieren willst, warum auch immer... dann ist so ein flag besser, weil dann hast du das erstaktivierungsdatum immernoch und musst nur des flag umstellen..

dies ist leider alles geschmacksache
greetz

[elrond]

ich schreibe an einer solchen stelle immer einen definierten nicht null-wert (1.1.1980) in eine solche spalte.

ist aber wie gesagt geschmackssache...

[Jasper]

ich schreibe an einer solchen stelle immer einen definierten nicht null-wert (1.1.1980) in eine solche spalte.

ist aber wie gesagt geschmackssache...

nicht nur geschmackssache. solche pseudo-nullwerte sollte man tunlichst vermeiden weil sie dem optimizer (sofern das verwendete DBMS überhaupt einen hat) falsche informationen liefern.
ein entwickler von uns hatte die gleiche glorreiche idee und hat nicht genutzte datumswerte auf 3.3.3333 gesetzt, weil er das datum schick fand. problem ist nur, dass der optimizer für seine vorhersage low- und highvalues verwendet um den wertebereich zu bestimmen (aus diesem grund ist die oftmals von javaentwicklern praktizierte verwendung von millisekunden anstelle von datumsangaben mit sekundengenauigkeit ebenfalls eine ganz schlechte idee).
im normalfall war der wertebereich von 1980-2005, also 25 jahre. mit diesem pseudowert vergrösserte sich der bereich plötzlich um mehr als 1000 jahre, was den optimizer natürlich zu einer anderen strategie veranlasst hat (es ist halt ein gewaltiger unterschied, ob ich daten eines jahres aus 25 oder aus 1000 jahren auswähle), sehr zum nachteil der performance.
deshalb IMMER null verwenden, wenn die spalte keinen wert hat, dafür ist null da. damit kann der optimizer (richtig) rechnen.

-j

[Turbohummel]

Das eine ist platzsparend und für die meisten Anwendungen völlig ausreichend,
das andere entspricht mehr der Normalform (Atomarität von Daten - keine doppelten Informationen) und ist eben flexibler.

[mwanaheri]

Flexibler bist du, wenn du für die Autorisation ein int2-Feld mit Fremdschlüssel nimmst. Dann kannst du auf einen Wertebereich referieren, z.B. undefiniert, autorisiert, zurückgezogen. Bool kann schnell mal eng werden, Datum ja/nein ebenso.

[Gaert]

Hallo,

in dem Umfeld in dem ich arbeite wird in der Regel mit Gültigkeitszeiträumen gearbeitet, d.h. man legt ein Gültigkeitsdatum fest... z.B. 01.01.2006 - 31.12.9999 - Erlischt eine Gültigkeit wird das "bis" datum entsprechend terminiert. Du benötigst zwar ein weiteres Feld, aber du erhälst damit eine historisch korrekte Darstellung, d.h. du kannst zu bestimmten Zeitpunkten zurückspringen und nachsehen, ob der Eintrag damals gültig war (vorrausgesetzt du legst einen neuen Datensatz an, wenn du einen terminierten Eintrag reaktivierst).

Gruß,

Gaert

[Jasper]

in dem Umfeld in dem ich arbeite wird in der Regel mit Gültigkeitszeiträumen gearbeitet, d.h. man legt ein Gültigkeitsdatum fest... z.B. 01.01.2006 - 31.12.9999 - Erlischt eine Gültigkeit wird das "bis" datum entsprechend terminiert. Du benötigst zwar ein weiteres Feld, aber du erhälst damit eine historisch korrekte Darstellung, d.h. du kannst zu bestimmten Zeitpunkten zurückspringen und nachsehen, ob der Eintrag damals gültig war (vorrausgesetzt du legst einen neuen Datensatz an, wenn du einen terminierten Eintrag reaktivierst).

siehe meine antwort an zu elronds post. warum für das endedatum nicht null verwenden? das ist logischer (es gibt halt (noch) kein endedatum, ergo immer noch gültig) und dem optimizer werden keine falschen werte untergeschoben, die ihn zu falschen ergebnissen kommen lassen. wenn die betreffenden spalten natürlich _niemals_ als prädikat verwendet werden, sind sie dem optimizer egal, aber ich würde erst gar nicht mit so einer m.E. unsitte anfangen.

-j

[Gaert]

siehe meine antwort an zu elronds post. warum für das endedatum nicht null verwenden? das ist logischer (es gibt halt (noch) kein endedatum, ergo immer noch gültig) und dem optimizer werden keine falschen werte untergeschoben, die ihn zu falschen ergebnissen kommen lassen. wenn die betreffenden spalten natürlich _niemals_ als prädikat verwendet werden, sind sie dem optimizer egal, aber ich würde erst gar nicht mit so einer m.E. unsitte anfangen.

-j

Hallo Jasper,

ich kann dieses "Optimizier Problem" welches du beschreibst ehrlich gesagt nicht ganz nachvollziehen. Eventuell hast du hierzu ein Beispiel parat, oder kannst das ganze noch ein wenig ausführen?
Die von mir beschriebene Lösung wird im SAP Umfeld haufenweise eingesetzt (z.B. im Organisations Management um Personen auf Planstellen zu setzen). Hierbei hat sich eben eingebürgert 99991231 als Datum anzugeben wenn ein Endedatum nicht definiert ist...

Eine 0 als Enddatum finde ich übrigens nicht logisch, da damit Abfragen wie
"SELECT person FROM pstellen WHERE pstelle = 'Chef' AND gueltig_von <= '20060221' AND gueltig_bis >= '20060221'" (Wer war gestern der Chef?) nicht mehr so einfach und generisch möglich sind.

Gruß,

Gaert