FB: Unique Index auf Datum und Uhrzeit

[hoika]

Hallo,
ah so, von der Seite gehst Du ran.
Also eigentlich dem Date als Fließkomma-Zahl prinzipiell misstrauen und alles auf Integer aufbauen.

Sekunden kann ich schon mal ausschließen, bleibt also Minutenzahl also:
1440 Minuten pro Tag übrig
60 min pro 1 h * 24 (24h pro Tag), also 60*24

Oh Mann, muss man wirklich so einen Murks wegen einem Unique Index auf Date machen ??? *wunder*

[Delphi.Narium]

Uhrzeit := Trunc((TDateTime - Trunc(TDatetime)) / (1 / 1440))

Mal aufgebröselt:

Datum := Trunc(TDateTime)
TagesAnteil := TDateTime - Datum
EineMinute := 1 / 1440
Uhrzeit := Trunc(TagesAnteil / EineMinute)

Datum würde hier dann die Anzahl der Tage (seit 30.12.1899) als Integer enthalten und Uhrzeit den Tagesanteil in Minuten als Integer.

Hoffentlich hab' ich jetzt keine zu großen Denkfehler gemacht.

[hoika]

Hallo,
kommt so im etwa hin.

[TigerLilly]

Du hast diesen Aspekt zwar nicht angesprochen, aber als Anregung:
1) Ein unique-Index, zu dem es in der Wirklich keine unique-Eigenschaft gibt, ist ein Design Flaw.
2) Ein unique-Index auf ein Datum/Zeit Attribut verbirgt meistens ein Designproblem.

[jobo]

Noch 2 Anmerkungen:
Ein Date Field mit Date und Time Anteil kann man auch unter Verwendung des Index auf Date abfragen indem man <between :gewünschtesDate and :gewünschtesDate+1 verwendet (Der Parameter darf natürlich dann keinen Timeanteil enthalten), analog mit >< Operatoren.
Gibt es den Bedarf auch reine Time Werte derart abzufragen, sieht es allerdings nicht so gut aus.
Ob es dann für das Time Abfrage Problem Anwendungsfälle gibt, sei mal dahin gestellt.

Neben den rechnerischen Verfahren für exakte DateTime Werte von Delphi.Narium kann man auch Textkonvertierung mit Cast nutzen oder mit AddDate (.. Intervall) arbeiten.

Diese Möglichkeiten bestehen hoffentlich auch im alten Dialekt.

[hoika]

Hallo,

Zitat:

TigerLilly

Es geht hier nicht ausschließlich um Datum/Uhrzeit,
sondern das sind zusätzliche Felder, die zusammen mit einem anderen Integer-Feld einen eindeutigen Wert erzeugen sollen.

Zitat:

Textkonvertierung mit Cast

Und damit entfällt das Suchen per Index. Das genau will ich nicht.
Das mit dem Between oder >= <= ist schon klar.

[DeddyH]

Und wenn man einfach ein neues Feld mit dem "abgeschnittenen" Datum anlegt, das per Trigger befüllt/aktualisiert wird? Das könnte dann VARCHAR oder INT sein, den Index legt man dann auf dieses Feld, so wie man das früher z.B. für einen case-insensitiven UNIQUE-Index auf VARCHAR-Felder machen musste.

[jobo]

Zitat von hoika:

Zitat:

Textkonvertierung mit Cast

Und damit entfällt das Suchen per Index. Das genau will ich nicht.

Da hab ich mich nicht verständlich ausgedrückt. Ich meinte die Befüllung der Werte.
Ob die per Mathematik zugeschnitten werden (wenn sie eh als Zahl reinkommen) oder mit Textfunktionen (wenn sie bspw. aus einem Textedit stammen oder einer Komponenten, die auch Stringausgabe liefert), sie landen in der gewünschten Genauigkeit in der Spalte und sind in diesem Range dann eindeutig und bieten das Datenmaterial für einen Unique/Primary Constraint (ob jetzt mit oder ohne andere Spalten)

Das Problem der Un-/Wirksamkeit des Index gilt erst bei der Abfrage, wenn dort bspw. auf der Spalte gecastet wird oder mit anderen Funktionen rumgesäbelt wird.
Erlaubt und sinnvoll ist die Anwendung von Funktionen natürlich wieder auf Parameter Seite.
(Indexwirksamkeit hat natürlich gar nichts mit dem Unique Constraint zu tun, sollte aber immer berücksichtigt werden.)

[p80286]

Zitat von hoika:

Oh Mann, muss man wirklich so einen Murks wegen einem Unique Index auf Date machen ??? *wunder*

Kommt darauf an welcher zeitlicher Abstand minimal zwischen zwei Einträgen liegen kann. Wenn die Auflösung des Datentyps kleiner als der minimale Abstand der Einträge ist, solltest Du keine Probleme haben.

Gruß
K-H

[Delphi.Narium]

Wenn die kleinste Auflösung Minuten sein soll, dann kann ich bei 'nem Floatwert innerhalb einer Minute noch ein paar tausend Floatwerte bekommen, die innerhalb dieser Minute liegen. Mein Index bleibt aber weiterhin eindeutig.

Wenn ich die Uhrzeit als Float habe, aber die Eindeutigkeit auf maximal einem Satz pro Minute liegen soll, komme ich nicht ohne Rechnerei (Datenmanipulation, Umrechnung ...) aus.