✔ [mySQL] lock/unlock von Tabellen oder lieber Unique

[WiZdooM]

Hallo

Ich mache mir gerade Gedanken, wie ich Einmaligkeit garantieren kann.

In einem Formular wird aus der mySQL-DB eine Nummer ausgelesen und diese um 1 erhöht, sodaß eine fortlaufende Nummer besteht.
Jetzt läuft diese Nummer in zwei Bereichen. Einmal zwischen 200 000 und 300 000 und zwischen 700 000 und 800 000.

In folgendem Beispiel wird nur der Bereich 200k bis 300k betrachtet.
Es befinden sich zwei Benutzer im selben Formular, die kleinste gespeicherte Nummer der Datenbank ist 200000, d.h. zum Zeitpunkt an dem das Formular geladen wird, bekommen beide Benutzer 200001 angezeigt.
Jetzt füllt der Benutzer Eins das Formular aus und schickt es ab. Es wird validiert, evtl Fehler werden angezeigt, welche eine erneute Validierung nach der Korrektur zur Folge hat. Ist alles okay, bekommt Benutzer Eins eine Druckansicht. Mit dem Klick auf Ausdrucken werden die Daten aus diesem Formular dann in die Datenbank eingetragen. Gleichzeitig wird die neue Nummer (200 001) in die Datenbank geschrieben.

Benutzer Zwei ist ja auch noch auf dem Formular und bekommt wie Benutzer Eins ebenfalls die 200 001 angezeigt, da ja zum Zeitpunkt des Ladens der Seite die größte gespeicherte Nummer 200 000 war. Schickt nun Benutzer Zwei das Formular ab würde er ebenfalls 200 001 in die Datenbank eintragen.

Das gilt es auf jedenfall zu verhindern.

Ich habe mir nun überlegt, die Tabelle mit einem "LOCK TABLES %Tabellenname% WRITE" ab dem Zeitpunkt, an dem die Daten aus der Validierung weitergegeben werden, zu sperren und nach dem Eintrag wieder zu Entsperren. Versucht nun jemand seine Nummer einzutragen, während die Tabelle gesperrt ist, bricht ja die Ausführung des SQL-Befehls ab. Ich würde nun hergehen und in die Übersichtsseite ein Refresh der Nummer anordnen wenn eben dieses Event getriggert wird.
Ich sehe nur das Problem, dass - wenn sich ein Benutzer in der Übersicht befindet und den Browser schließt, dieser Lock nicht mehr aufgehoben wird und somit niemand mehr in die Tabelle schreiben kann.

Eine andere Möglichkeit ist wohl die Nutzung der UNIQUE-Deklaration einer Spalte. Ist es in dem Fall sinnvoller direkt dann auf die Uniqe-Deklaration aufzulaufen oder sollte ich hier mit lock/unlock arbeiten ? Was meint ihr ?

 

[Sprint]

Die Tabelle zu sperren, halte ich für nicht brauchbar. Ich frage mich, warum der Benutzer seine Nummer schon erfahren muß, bevor er überhaupt eingetragen ist. Ich würde nach der Vorlage seiner Eingaben, also da wo bei dir jetzt der Button zum ausdrucken ist, erst einmal die Daten schreiben. Dann erhält er seine endgültige Nummer und dann zeigst du entweder nochmal an zum drucken oder erstellst ein PDF und zeigst es an. Das kann er sich dann auch gleich noch runterladen.

 

[dbwizard]

Hallo
Ich mache mir gerade Gedanken, wie ich Einmaligkeit garantieren kann.

- Die brauchst du dir nicht zu machen. Dafür gibt es PrimaryKeys, und die sind auch die EINZIGE Lösung

Ich habe mir nun überlegt, die Tabelle mit einem "LOCK TABLES %Tabellenname% WRITE" ab dem Zeitpunkt, an dem die Daten aus der Validierung weitergegeben werden, zu sperren und nach dem Eintrag wieder zu Entsperren.

- Du willst deine Applikation aber schon mit mehr als 1 =[EINEM] User betreiben ? Für ein MultiUsersystem ist solch ein Vorgehen schlichtwegs "unbrauchbar"

- Du musst einen PrimaryKey definieren. Dieser muss durch eine Sequence oder wie auch immer dies in MYSQL lautet, erzeugt werden (Also nicht solch obskure Vorgehensweisen wie "Hohle mir die höchste Nummer und zähle 1 dazu...)

Gruss



Gruss

 

[WiZdooM]

Die Tabelle zu sperren, halte ich für nicht brauchbar. Ich frage mich, warum der Benutzer seine Nummer schon erfahren muß, bevor er überhaupt eingetragen ist. Ich würde nach der Vorlage seiner Eingaben, also da wo bei dir jetzt der Button zum ausdrucken ist, erst einmal die Daten schreiben. Dann erhält er seine endgültige Nummer und dann zeigst du entweder nochmal an zum drucken oder erstellst ein PDF und zeigst es an. Das kann er sich dann auch gleich noch runterladen.

Ganz einfach - weil es die Geschäftsleitung so WILL :/
Vielleicht sollte ich noch erwähnen, dass dem Benutzer beim Ausfüllen des Formulars nicht alle Daten vorliegen. Der Benutzer ist ein Autohändler, der einem Kunden ein Auto verkauft. Diese Daten werden - sofern vom Kunden gewünscht - elektronisch erfasst und in meine DB geschrieben. Wenn jetzt der Benutzer (Händler) voreilig ist und sich Arbeit sparen will und schon zb die Fahrzeugdaten einträgt, schreibt er den unvollständigen Satz in die DB und z.Z besteht noch keine Möglichkeit dem Benutzer diese Daten zur Korrektur NACH Eintragung zugänglich zu machen- aber die Nummer bereits vergeben. Weiterhin kann es auch sein, dass der Benutzer bereits alle Daten hat, diese Einträgt aber der Kunde will es nicht. Dann ist der Datensatz ungültig - aber die Nummer bereits vergeben.

- Die brauchst du dir nicht zu machen. Dafür gibt es PrimaryKeys, und die sind auch die EINZIGE Lösung



- Du willst deine Applikation aber schon mit mehr als 1 =[EINEM] User betreiben ? Für ein MultiUsersystem ist solch ein Vorgehen schlichtwegs "unbrauchbar"

- Du musst einen PrimaryKey definieren. Dieser muss durch eine Sequence oder wie auch immer dies in MYSQL lautet, erzeugt werden (Also nicht solch obskure Vorgehensweisen wie "Hohle mir die höchste Nummer und zähle 1 dazu...)

Gruss



Gruss

Ein Primary Key ist bereits definiert und zwar der autoinkrementelle Index.
Dieser Primary Key ist VORGEGEBEN, ich DARF den NICHT einfach so erweitern. Wenn es nur um das eine Feld ginge wäre mir das wurst, aber es hängen da etwa 30 Felder dran, da die Daten aus einer Access-DB exportiert und in die MySQL für die Onlineverwaltung importiert werden und wieder zurück. Ist nicht meine Idee gewesen, aber es muss leider so gemacht werden, da sich meine Vorgänger keine Gedanken gemacht haben.

Und ich soll mir da keine Gedanken machen ? Ihr macht mir Spaß xD

 

[Sprint]

Meine Erfahrung mit Chefs läuft darauf hinaus, daß die GL nicht das bekommt, was sie will, sondern das will, was sie bekommt. Selbst dem dümmsten Chef sollte ein gut erklärtes "geht nicht" oder "ist völlig unpraktikabel" einleuchten.
Ansonsten bleibt nur noch, am Anfang den Datensatz anzulegen und die Nummer mitlaufen zu lassen bis entweder alle Daten eingetragen werden oder die Nummer versch... ist. bei 100.000 Nummern dürfte aber auch ein 20% Ausschuß noch tragbar sein.

 

[WiZdooM]

Das mein lieber Sprint ist wohl wahr.
Aber dank der kritischen Frage deinerseits am Anfang war die Lösung dieses Problems doch einfacher als Anfangs vermutet.

Thx.