nicht angemeldet
Unique-Constraints für Bereiche
Hallo,
ich habe eine Datenbank (momentan auf MySQL, aber ich hoffe, mich gegebenenfalls auch mit anderen Systemen [am ehesten wohl PostgreSQL] anfreunden zu können) mit einer Datetime-Spalte. Ich würde gerne einen Constraint schreiben, der ein Datum eindeutig macht. Das kniffelige: Es soll nicht nur genau dieses Datum einmal auftauchen, sondern der ganze Block vom Datum bis bspw. zehn Tage später. Wenn also ein Datensatz das Datum 01.01.2001 00:00 trägt, muss das Constraints alle Datensätze ablehnen, die zwischen diesem Datum umd 11.01.2001 00:00 liegen. Das dann halt auch auf alle eingetragenen Datensätze übertragen.
Ich habe, abgesehen von vorher erst mal ein SELECT…WHERE von aufrufenden Proramm schicken, keine wirkliche Idee. Im Kontext PostgreSQL hat man mir noch von Check-Constraints erzählt, wovon ich keine Ahnung habe, und die MySQL nach Dokumentation offensichtlich ignoriert.
Wie würdet ihr so ein Problem lösen?
Grüße,
Fabian.
-
Hallo
Ich habe, abgesehen von vorher erst mal ein SELECT…WHERE von aufrufenden Proramm schicken, keine wirkliche Idee. Im Kontext PostgreSQL hat man mir noch von Check-Constraints erzählt, wovon ich keine Ahnung habe, und die MySQL nach Dokumentation offensichtlich ignoriert.
da nicht unterstützt.
Wie würdet ihr so ein Problem lösen?
entweder INSERT- und UPDATE-Operationen nur über Stored Procedures zulassen, die Deine Bedingungen überprüfen oder mit INSERT- und UPDATE-Triggern. Beides erfordert MySQL 5.0 oder neuer.
Freundliche Grüße
Vinzenz
-
Hallo,
oder mit INSERT- und UPDATE-Triggern.
Trigger scheine ich noch nicht richtig verstanden zu haben: Für mich ist ein Trigger ein Stückchen Code, das vor/nach einem entsprechenden Ereignis ausgeführt wird. Wie kann ich aber dann verhindern, dass der INSERT-Prozess ausgeführt wird, und dem aufrufenden Programm noch ein entsprechendes Signal geben, so wie ich es bei verletzten Constraints bemerken würde?
Beides erfordert MySQL 5.0 oder neuer.
Und wie würde es aussehen, wenn ich PostgreSQL verwenden würde? Ich bin denke ich mal sowieso nicht so in der Materie drin, als das ein Umstieg so aufwändig wäre (zumal mir auch noch einige andere Leute zu PostgreSQL geraten haben).
Grüße,
Fabian.
-
Hallo
Und wie würde es aussehen, wenn ich PostgreSQL verwenden würde? Ich bin denke ich mal sowieso nicht so in der Materie drin, als das ein Umstieg so aufwändig wäre (zumal mir auch noch einige andere Leute zu PostgreSQL geraten haben).
CHECK-CONSTRAINTS helfen hier auch nicht, ich zitiere aus dem entsprechenden Handbuchabschnitt:
<zitat>
CHECK ( expression )The CHECK clause specifies an expression producing a Boolean result which
new or updated rows must satisfy for an insert or update operation to
succeed. Expressions evaluating to TRUE or UNKNOWN succeed. Should any row
of an insert or update operation produce a FALSE result an error exception
is raised and the insert or update does not alter the database. A check
constraint specified as a column constraint should reference that column's
value only, while an expression appearing in a table constraint can
reference multiple columns.Currently, CHECK expressions cannot contain subqueries nor refer to
variables other than columns of the current row.
</zitat>Die sauberste Lösung wären Stored Procedures. Du erzwingst die Verwendung dieser Stored Procedures, indem *kein einziger* DB-Benutzer das INSERT oder UPDATE-Recht für diese Tabelle erhält, nur Ausführberechtigungen für die entsprechenden SPs.
Freundliche Grüße
Vinzenz
-
Hallo,
Ich werde deinen Rat befolgen und Stored-Procedures verwenden. Das dürfte der einfachste Ansatz sein (abgesehen von vrher ein Query absetzen). Die einzige Frage die mir bleibt: Wie kann ich dann den das Query absetzenden Kontext davon wissen lassen, dass es eben nicht geklappt hat?
Noch mal zu CHECK (nur der Neugierde halber): Jemand hatte mir einen CHECK Constraint gezeigt, der eben als Expression eine Funktion ausführt. Leider kann ich mich an keine Details mehr erinnern, sodass ich Dir hier seinen Code leider nicht hinschreiben kann, obwohl das sicherlich für mein Verständnis hilfreich wäre. Wäre denn für Dich ein solches Konstrukt prinzipiell denkbar?
Grüße,
Fabian.
-
-
-