MySQL: "unique"-artig, über mehrere Datensätze:-|

[TS]

Hello,

Wieweit einem ein Pre-Insert Trigger auf die atomaren Beine helfen kann, weiß ich nicht.

Keide4r gar nicht. Der kann nur helfen, ohnehin Sinnloses gar nicht erst zu probieren. Und wenn man dann das Update durchgeführt hat, muss man trotzdem noch testen, ob nicht trotzdem Unerlaubtes passiert ist, also noch einen after-Update-Trigger ausführen, der ggf. den DS wieder löscht.

Das Problem liegt aber mMn in der falschen Modellierung. WIe ich schon schrieb, sollte man das Modell dahingehend ändern (vereinfacht):

Anzahl_pro_Tisch        Buchungen
-------------—–-        ---------------—-- 
id_tisch                id_tisch            | ggf. unique
anzahl (0 .. n)         Platz-Nr   (1 .. n) | index
                        Name
                        Kontodaten

Man kann dann die Limiten unabhängig von der nachgeschalteten eigentlichen Buchung prüfen. Das geht auch ganz ohne Transaktion und Sperren, denn ein
update anzahl_pro_tisch set anzahl = anzahl + x where (anzahl + x) < $max
ist als Update atomar und somit nicht zu stören durch andere Requests. Die Eintragung in die Buchungsliste kann dann bei Erfolg des Update-Statements ebenfalls erfolgen. Die Platznummern würde man hier der Reihe nach vergeben, sie sind nicht vorbestellbar. Sonst wirds noch kompilzierter.

Und normalisieren könnte man selbstverständlich auch noch und eine zus- Kundentabelle anlegen mit Namen, Anschrift, Kontodaten.

Liebe Grüße
Tom S.