FB: Unique Index auf Datum und Uhrzeit

[hoika]

Hallo,
Waffenstillstand

Aber schön geschrieben und stimmt sogar.

Setzen: 1+

[jobo]

Es waren Waffen im Spiel?

[p80286]

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

[alex517]

Zitat von p80286:

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

Ich möchte mich nicht streiten, auch nicht fröhlich aber,
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.

[hoika]

Hallo,

Zitat:

Unique Index das richtige ist um Doubletten

Wie weiter oben schon schön erklärt wurde, ist es nicht Index, sondern das Unique Constraint,
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.

[jobo]

Zitat von hoika:

ist es nicht Index, sondern das Unique Constraint,
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.

Das sehe ich auch so. Der Unique constraint ist die letzte Instanz, die im Fehlerfall zuschlägt.
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.

[hoika]

Hallo,

Zitat:

Vor dem Insert manuell auf Eindeutigkeit zu prüfen macht m.E. keinen Sinn

Doch macht es, weil man dann eine schöne Meldung bringen kann ala "Datensatz bereits vorhanden".
Aus der DB-Exception herauszufinden, warum der Datensatz nicht angelegt werden konnte, ist schwerer.