FB: Unique Index auf Datum und Uhrzeit

[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.

[hoika]

Hallo,
ich mag keine Trigger
Nö, ich mach das jetzt mit den Extra-Feldern als String.
Ich bin ja der der die Dateneingabe schreibt, und ändern soll sich das auch nicht lassen.

[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.)

[hoika]

Hallo,
ok.

Zitat:

Das Problem der Un-/Wirksamkeit des Index gilt erst bei der Abfrage,

Nein, die Wirksamkeit beginnt bei mir beim Insert.
Dass ich da auch was abfragen kann, ist mir erst mal nebensächlich.
Ich will verhindern, dass im Mehrnutzerbetrieb aus Versehen ein doppelter Datensatz erzeugt wird.
Im Programm prüfe ich das natürlich vorher selbst, aber sicher ist sicher.

[jobo]

Zitat von hoika:

Zitat:

Das Problem der Un-/Wirksamkeit des Index gilt erst bei der Abfrage,

Nein, die Wirksamkeit beginnt bei mir beim Insert.

Ich will verhindern, dass im Mehrnutzerbetrieb aus Versehen ein doppelter Datensatz erzeugt wird.
Im Programm prüfe ich das natürlich vorher selbst, aber sicher ist sicher.

Ich glaube Du vermischt da etwas, was nichts miteinander zu tun hat.
Wie auch immer der Wert beim Insert in die Spalte kommt, geradewegs, mit Funktion verdreht, gekürzt, was auch immer. Der Index wirkt und wird im Falle eines Primary Key Constraint vom Server genutzt um den Primary Key Constraint zu überprüfen.

Die Genauigkeit des Wertes, der eingefügt wird in Kombination mit vorhandenen Werten entscheidet lediglich über das Ergebnis der Primary Key Konstraint Prüfung. Je größer die Genauigkeit, desto unwahrscheinlicher eine Verletzung des Constraints. Je geringer die Genauigkeit, desto wahrscheinlicher die Verletzung (Was natürlich gewollt sein kann, eben ab dem Punkt, auf den man die Genauigkeit justiert)

Startest Du dagegen eine Abfrage und benutzt bspw. Funktionen auf der Spalte, wirkt der Index nicht mehr (im Sinne einer Beschleunigung des Zugriffs)

Ja und nur zur Klarheit in der Diskussion:
Index != Key != Primar Key != Primary Key Konstraint
Bedeutet, das Löschen aller Indizes in der DB ändert nichts an der Eindeutigkeitslogik in Deinem DB Modell, es wird nur alles ziemlich langsam. (Und man müsste sich keine Gedanken mehr über die Wirksamkeit von Indizes in Abfragen machen)

[hoika]

Hallo,
Einspruch Eurer Ehren

Zitat:

das Löschen aller Indizes in der DB ändert nichts an der Eindeutigkeitslogik in Deinem DB Modell

Unter Firebird wird die Eindeutigkeit mit Hilfe eines Unique-Index sichergestellt.
Lösche ich den Unique-Index ist auch das Unique-Constraint weg, zumindestens unser FB.
Genauer gesagt, gibt es gar kein Unique-Constraint ohne Unique Index, oder irre ich mich da?

Und genau die Frage der Wahrscheinlichkeit eines "ungenauen" Unique-Index ist ja für mich die Frage.
Speichere Ich eine Uhrzeit, die sich um das 1/1000-tel einer Minute zu einem bestehenden Datensatz unterscheidet, wäre das "doof".
Deshalb speichere ich jetzt Datum und Uhrzeit zusätzlich als String, dessen Format von mir definiert wird,
und genau diese String-Felder neutze ich u.a. für den Unique Index.

[jobo]

Zitat von hoika:

Hallo,
Einspruch Eurer Ehren

Einspruch abgelehnt!

es ging mir erstmal um klare Begriffe. Index versus Constraint, ...
Die Technik: Moderne Datenbanken bieten normalerweise alle (Halb)Automatiken, die einen Index anlegen, sobald ein (Primary)Key-Constraint definiert wird und dann auch umgekehrt, wenn ein Constraint gelöscht wird, wird der Index gelöscht usw usf. Der Index eine ist eine Hilfsdatenstruktur zur Beschleunigung von Abfragen**, der Constraint eine logische Regel.
Darüber hinaus kann man natürlich Indizes selbst definieren (ohne Zusammenhang mit einem Schlüsselkonstraint)

Du möchtest einen Primary Key Constraint über mehrere Felder inkl Date, Time Spalte.
Das soll Eindeutigkeit garantieren, dazu sind diese Konstrukte da, kein Thema. Wird auch funktionieren.
Date / Time haben den "kleinen Randeffekt" mit der Genauigkeit, die musst/kannst Du nach Bedarf justieren (durch Beschneiden der Werte).

Die Problematik mit der Wirksamkeit eines Index zur Beschleunigung hat damit nur am Rande etwas zu tun. Eben bei einer Abfrage, niemals bei einem Insert*.
Wirken tut und wirken soll beim Insert dagegen die Eindeutigkeitsregel, der Primary Key Constraint. Die Überprüfung eines neue Wertes oder Wertegruppe wird beschleunigt durch einen ebenfalls existierenden-weil meist automatisch angelegten- Unique Index, der die vom Server automatisch durchgeführte Suche nach einem bereits vorhandenen, identischen Wert beschleunigt. Auch hier stören keine Casts oder was auch immer.

*die negative Beschleunigung eines zu aktualisierenden Index bei Insert mal außen vor gelassen
** indirekt werden so auch Inserts beschleunigt- durch beschleunigte Abfragen auf Duplikate

Meinetwegen können noch weitere Zeugenaussagen gemacht werden. Ich vertage mich.

[hoika]

Hallo,
Waffenstillstand

Aber schön geschrieben und stimmt sogar.

Setzen: 1+