[Erledigt] Datenbankwerte sinnvoll OB etwas gilt, obwohl Werte vorhanden sind? (Best

[Forumsgast]

Hallo,

nehmen wir an, es sind Arbeitsverträge in der DB.
Arbeitsverträge können vorzeitig beendet werden, daher gibt es das Feld "termination_date" als Date Feld.

Macht es dann einen Sinn, ein extra Feld "terminated_early" als tinyint (1 oder 0) einzupflegen?
(Wird ausgefüllt je nachdem OB der Vertrag vorzeitig beendet wurde oder nicht)

Kopfgefühl:
OB ein Vertrag vorzeitig beendet wurde kann dadurch herausgefunden werden, ob "termination_date" leer ist oder nicht. Daher ist das Feld sinnlos.
Damit hat das "terminated_early" keine Funktion mehr.

Bauchgefühl:
Es ist vllt. best practice auf 1 oder 0 zu checken anstatt das "termination_date" dafür zu missbrauchen.

Bin auf eure Meinungen gespannt.

[Forumsgast]

Was genau hat das jetzt mit PHP zu tun?

[Forumsgast]

Ein Vertrag kann auf unbestimmte Zeit geschlossen sein, dann gibt es kein vorher bestimmtes Ablaufdatum.
Ein Vertrag kann auf eine bestimmte Zeit geschlossen sein, dann gibt es ein vorher bestimmtes Ablaufdatum und das steht in der Tabelle.
Wird er Vertrag vor Erreichen des vorher bestimmten Ablaufdatums aufgelöst, so ist er eben vorzeitig aufgelöst. Das läßt sich per Abfrage ermitteln:
Wenn 'Auflösedatum' kleiner 'ursprünglich_vereinbart' dann 'vorzeitig'.

Ein Normalisierungsproblem stellt sich insoferne, als ich den auf unbestimmte Zeit geschlossenen Verrägen ein NULL-Datum als vereinbartes Ablaufdatum geben müßte. Unter Umstände könnte es auch sinnvoll sein, das Ablaufdatum in einer separaten Tabelle abzulegen, dann brauchen keine NULL-Werte gespeichert zu werden.

Das gehört doch in die Abteilung Datenbanken, oder?

[Forumsgast]

Du, achtelpetit & Nikosch haben Recht, es gehört in die DB Sektion.

Betriebsblindheit
Verschiebst du es bitte?
Das nächste Mal passe ich besser auf.

@achtelpetit
Genau das hatte ich oben beschrieben?
Durch das NULL setzen wird das Feld 'eigentlich' nicht benötigt.

Die Frage ist, ob man 'termination_early' als "best practice" trotzdem lässt oder über IS NOT NULL abfragt und das Feld spart.

[Forumsgast]

Wenn Du Beginn und Ende des Vertrags kennst, wäre ein weiters Feld redundant. Es kann dann Konflikte verursachen: wenn laut Datendifferenz der Vertrag nicht vorzeitig beendet wurde, das Ja/nein-Feld den Vertrag aber als vorzeitig beendet qualifiziert.
Alles, was über eine Abfrage bestimmt werden kann, braucht und darf nicht als zusätzliches Feld geführt werden.

und das Feld spart.

Felder sparen ist keine Kategorie beim DB-Entwurf.

[Forumsgast]

DatumBeginn          | 
DatumBefristetBis    | 
DatumBeendigung      | 
ArtBeendigung (Kündigung, Änderungskündigung, Bedingung, Aufhebung, Anfechtung)

[Forumsgast]

Wenn Du Beginn und Ende des Vertrags kennst, wäre ein weiters Feld redundant. Es kann dann Konflikte verursachen: wenn laut Datendifferenz der Vertrag nicht vorzeitig beendet wurde, das Ja/nein-Feld den Vertrag aber als vorzeitig beendet qualifiziert.
Alles, was über eine Abfrage bestimmt werden kann, braucht und darf nicht als zusätzliches Feld geführt werden.
Felder sparen ist keine Kategorie beim DB-Entwurf.

Super Erklärung, danke!
Feld wird also entfernt.

@nikosch
Danke für die unterschiedlichen Arten der Beendigung.