FB: Unique Index auf Datum und Uhrzeit

[hoika]

Hallo,
gegeben ist folgende Tabelle:

Id Integer
PersonalId Integer
Datum Date
Uhrzeit Date

So wie es oben schon steht, suche ich eine Möglichkeit, zu verhindern,
dass zur gleichen PersonalId ein Eintrag mit gleicher PersonalId, Datum und Uhrzeit erzeugt wird.
Da Date ja intern Float ist (?), steht für mich die Frage, ob dass über

Unique Index Test on (PersonalId, Datum und Uhrzeit)

funktionieren kann?

[jobo]

In Oracle kann Date Type auch Uhrzeiten enthalten.
Wenn das bei FB genauso ist, wäre es fast Glücksache, dass es per Primary Key Constraint über diese Spalte funktioniert.

Wenn die Tabelle nicht bereits tief in Bearbeitung ist und FB auch die Uhrzeit in Date Spalten speichern kann, dann würde ich dazu tendieren, die beiden Spalten zusammenzulegen, also die Spalte Uhrzeit wegzuwerfen.

Trotzdem ist natürlich die Uhrzeit in dem Format auch mit einer gewissen Genauigkeit im hundertstel Bereich gespeichert, was ggF. zu den von Dir befürchteten Effekten führt.

Man kann das aber runden / truncaten, z.B. auf Minuten oder halt so exakt, wie du es brauchst. Dann hast Du im Rahmen der Genauigkeit einen Unique Key (Primary)

[dataspider]

Sicher funktioniert das.
Die Frage ist nur, ob Einträge mit 1 Sekunde Abweichungen tatsächlich akzeptiert werden sollen oder nicht.
Wenn nicht, dann sollte man das eher über einen Trigger lösen und die erlaubte Abweichung berücksichtigen.

Frank

[Delphi.Narium]

Hilft die Seite weiter? Firebird - Data Types for Dates and Times

In Dialect 3 enthält der Datentyp Date nur das Datum ohne Uhrzeit, der Datentyp Time ist ausschließlich für die Uhrzeit.

Wenn dem wirklich so ist, stellt sich für mich erstmal die Frage: Was ist bei Deiner Tabelle tatsächlich in den Spalten Datum und Uhrzeit enthalten.

[hoika]

Hallo,
mir geht es hier in der Tat nur darum,
ob ein Unique Index auf ein Date-Feld wirklich sauber Dopplungen erkennt.

[Delphi.Narium]

ja

Ein Index auf eindeutige Werte kann einen Wert nur einmal enthalten, der Datentyp (die Datentypen bei mehreren Spalten im Index) ist dabei egal.

[himitsu]

Zitat von jobo:

In Oracle kann Date Type auch Uhrzeiten enthalten.

Das wäre auch besser, denn sein Uhrzeit-Feld ist ja auch als DATE und nicht als TIME deklariert.

Jupp, also theoretisch würde der Index ja funktionieren. (aber wie bereits genannt wurde, gibt es das Hindernis mit den ungenauen Werten)
CREATE UNIQUE INDEX DeineTabelle_id_datetime ON DeineTabelle (PersonalId, Datum, Uhrzeit)

Aber zur Sicherheit kannst du deine Zeit-Werte auch im Index umrechnen/casten, zusammenfassen und vor allem auf ein gewünschtes Maß "runden".
z.B. beim Datum die eventuelle Uhrzeit entfernen und die Uhrzeit auf Sekunden runden. (Trunc/Extract)

SQL-Code:

CREATE UNIQUE INDEX DeineTabelle_id_datetime ON DeineTabelle COMPUTED BY (PersonalId, CAST(Datum AS DATE), CAST(Uhrzeit AS TIME));  -- Cast geht wohl nicht, wenn DATE = DATETIME
CREATE UNIQUE INDEX DeineTabelle_id_datetime ON DeineTabelle COMPUTED BY (PersonalId, Trunc(Datum) + (Uhrzeit - Trunc(Uhrzeit)));
CREATE UNIQUE INDEX DeineTabelle_id_datetime ON DeineTabelle COMPUTED BY (PersonalId, DateAdd(Trunc(Datum), Uhrzeit));
...

Einen Cast/Round um Uhrzeit auf Sekunden zu runden oder ein Cast(Extract(Uhrzeit, SecondOfDay) AS INTEGER) gibt es wohl nicht?

Zitat:

Aus der DB-Exception herauszufinden, warum der Datensatz nicht angelegt werden konnte, ist schwerer.

Gut, man könnte auch über einen BeforeInsert-Trigger alles "nochmals" prüfen und eine bessere Fehlermeldung ausgeben.
Genauso kann man aber dem UniqueIndex auch einen sprechenden Namen geben, da er doch in der Fehlermeldung genannt wird.
Man könnte sich auch in die Error-Events der Connection/Querykomponente hängen und da den Triggernamen übersetzen, bzw. die Fehlermeldung um etwas Verständlicheres ergänzen.