![]() |
AW: FB: Unique Index auf Datum und Uhrzeit
Zitat:
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) |
AW: FB: Unique Index auf Datum und Uhrzeit
Hallo,
Einspruch Eurer Ehren ;) Zitat:
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. |
AW: FB: Unique Index auf Datum und Uhrzeit
Zitat:
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. |
AW: FB: Unique Index auf Datum und Uhrzeit
Hallo,
Waffenstillstand ;) Aber schön geschrieben und stimmt sogar. Setzen: 1+ |
AW: FB: Unique Index auf Datum und Uhrzeit
Es waren Waffen im Spiel?
;) |
AW: FB: Unique Index auf Datum und Uhrzeit
Hätten sein können!
Als Hoika schrieb Insert fiel mir eine Passage in irgendeinem Datenbankhandbuch ein "Wenn Du einen Unique Index nutzt und eine Doublette eingefügt wird, gibt es eine Fehlermeldung" und jetzt kann man fröhlich darüber streiten ob ein Unique Index das richtige ist um Doubletten zu vermeiden..... Gruß K-H |
AW: FB: Unique Index auf Datum und Uhrzeit
Zitat:
das Einfügen von Doubletten sollte bereits vorher vermieden werden. Mit dem unique constraint wird jedoch die Integrität der Datenbank sichergestellt, damit es mit Sicherheit keine Doubletten gibt. |
AW: FB: Unique Index auf Datum und Uhrzeit
Hallo,
Zitat:
was die Doubletten verhindert, und somit die Integrität der Datenbank sichert. Der Unique Index wird von Firebird zusätzlich angelegt, um schneller nach einem eventuell vorhandenen Wert zu suchen. Wie soll ich denn sonst verhindern, dass Doubletten in die Datenbank kommen. Soll etwas ausschließlich das Programm das prüfen? Was ist, wenn quasi gleichzeitig 2 gleiche Einträge angelegt werden, oder es einen Bug im Programm gibt? Als letzte Instanz muss ich der DB sagen können, dass ich da keine Doubletten gibt. |
AW: FB: Unique Index auf Datum und Uhrzeit
Zitat:
Konzeptionell kann man das natürlich ganz verschieden einsetzen. Bspw. Zufallszahlen als ID eintragen und immer wenn es sie schon gibt, knallt es halt. Oder es dem User überlassen, so lange eingeben, bis es nicht knallt. Oder die gängige Variante, eine Sequenz. Knallt selten. Oder UUID usw. Vor dem Insert manuell auf Eindeutigkeit zu prüfen macht m.E. keinen Sinn. Das macht die DB mit dem Unique Constraint sowieso. Also doppelte Arbeit und die eine Hälfte vielleicht auch noch vergeblich, weil nach der manuellen Prüfung ja schon Zeit wäre, wo sich der Datenstand verändert. (außer..egal) Also sinnvoll ist eine ID Quelle, die auf natürliche Weise Eindeutigkeit garantiert oder halt zu 99,xy %. Und da schließt sich der Kreis, denn man könnte bspw. Datum / Uhrzeit nehmen. Soetwas muss natürlich mit der Entstehungsfreuenz der Datensätze dann abgestimmt sein. "Beschießt" man das System bewusst mit nicht eindeutigen Werten, kann man sich zwar auf den Constraint verlassen, aber verpulvert natürlich ohne Not sehr viel Ressourcen. Wer's mag.. Ich glaube nicht, dass das im Sinne eines Höhentrainings unter Sauerstoffmangel später zu einer Leistungssteigerung des Systems führt, wenn es wieder normal genutzt wird. Training ist für KI Systeme, nicht für Fehlerbehandlungsroutinen. |
AW: FB: Unique Index auf Datum und Uhrzeit
Hallo,
Zitat:
Aus der DB-Exception herauszufinden, warum der Datensatz nicht angelegt werden konnte, ist schwerer. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:40 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz