|
||||
Datenbank Verständnis Problem
Hallo miteinander,
irgendwie habe ich ein Brett vor dem Kopf Fall 1: Datenbank - zwei Benutzer lesen einen Datensatz aus und verändern diesen. Der eine geht erst mal einen Kaffee holen, der andere speichert seine Änderungen. Sieht der Kaffeetrinker noch die alten Daten in seinem Formular? Fall 2: Datenbank - zwei Benutzer lesen einen Datensatz aus und verändern diesen. Beide drücken zur gleichen Sekunde (Millisekunden eingerechnet) auf Speichern. Welcher der Änderungen liegt nun in der Datenbank? Sollte man vor dem Speichern die eingelesenen Daten mit den aktuellen Daten in der Datenbank vergleichen? Hintergrund: Locking Funktion, OK, Software (Qualität) abhängig . Kann mir da einer von euch etwas Licht ins Dunkel bringen?
__________________
Personal stuff |
Sponsored Links |
Sponsored Links |
|
||||
Fall1: Der User sieht immer noch die alten Daten. Die Daten werden nicht verändert in dem Formular, da der Browser den Server auf Userwunsch nach den Daten fragt, nicht der Server dem User Bescheid sagt.
Als Lösung könntest du dem zweiten User Bescheid geben, dass bereits ein weiterer User die Daten bearbeitet. Fall2: Der User der zuletzt schreibt, dessen Daten stehen in der Datenbank. Es können zwar beide zeitgleich absenden - es ist aber sehr unwahrscheinlich bei wenigen Usern - es kann aber immer nur einer schreiben. Der Datensatz wird vor dem Schreiben gesperrt. Welcher von den beiden zuerst schreibt, ist aber nicht zu sagen. Dabei hilft dann aber auch der Lösungsvorschlag von Nummer eins. Einen Datensatz beim Abrufen zu sperren und nach dem Schreiben wieder freizugeben, ist nicht zu empfehlen. Es kann sein, dass der User seine Bearbeitung nie beendet... Du kannst natürlich auch die alten mit den aktuellen Daten vergleichen, das kann aber Zeit in Anspruch nehmen Edit: Ich sehe gerade mantiz war ein paar Sekunden schneller
__________________
Rettet die Erde.... sie ist der einzige Planet mit Schokolade! Geändert von Praktikant (24.07.2011 um 20:10 Uhr) |
|
||||
Ihr habt aber beide nur an Myisam & Co gedacht, das Mittel der Wahl um genau solche Probleme zu vermeiden sind Transaktionen. Wer also PostgreSQL oder Mysql mit InnoDB verwendet, kann Transaktionen nutzen und so würde der Kaffetrinker nicht die Daten des anderen überschreiben, sondern die Transaktion würde abgebrochen, zurückgerollt und er könnte einen hübschen Hinweis präsentiert bekommen, wo zum Beispiel seine Version mit der neuen aktuellen Verglichen verglichen wird. Im zweiten Fall würde auch nur eine Transaktion erfolgreich sein, die Zweite würde ebenfalls abgebrochen.
|
|
||||
Könntest Du das weiter ausführen?
Ich sehe nicht, dass Transaktionen hier helfen könnten, aber vielleicht bin ich im Moment einfach nur blind. Mein Ansatz wäre das letzte Bearbeitungsdatum zum Datensatz zu speichern und dieses ebenfalls z.B. als Hidden-Field mit zu übertragen. Dann könnte man ein Code:
UPDATE ... WHERE `id` = x AND `lastModified` = '...' Und da es sich bei dem Update eigentlich nur um ein Statement handelt, sehe kein Einsatzgebiet für Transaktionen. Wenn das mit Transaktionen aber einfacher geht, dann klär' mich bitte auf, ich lerne gerne dazu. |
|
||||
Zitat:
Wenn alle Zugriffe auf die Datenbank mit Transaktionen erfolgen, dann kann es nicht zu dem Fall kommen, dass sich zwei Aktionen überschneiden. Die Transaktion die zuerst abgeschlossen wurde gewinnt, alle folgenden werden abgebrochen und zurückgerollt. Damit hat man eigentlich alle Probleme die es beim Zugriff geben kann erschlagen (abgesehen von Deadlocks). Ich habe das Gefühl, dass ihr genau dieses Verhalten versucht mit einer eigenen Lösung zu simulieren, oder sehe ich das falsch? |
|
||||
Vielleicht reden wir auch aneinander vorbei.
Ich rede insbesondere von dem ersten Fall. Der Ablauf ist ja z.B. wie folgt: 1. User A öffnet Datensatz A zum bearbeiten 2. User B öffnet Datensatz A zum bearbeiten 3. User B speichert Datensatz A 4. User A speichert Datensatz A In Schritt 4 wird ja im Prinzip nur genau ein Statement (UPDATE ...) zur DB geschickt, ob dieses nun innerhalb einer Transaktion läuft oder nicht, ist doch völlig uninteressant, oder? So oder so würden die Daten von User B überschrieben werden, da Transaktionen nur innerhalb eines Scriptlaufs aktiv sein können. Zitat:
|
|
|||
Du hast ja effektiv zwei oder mehr Zeitspannen vom Zeitpunkt des Aufrufs bis zum Zeitpunkt der Speicherung
Code:
---A-------------S------------ ---------A--------------S----- ---A------------------S------- ---------A------S------------- Geändert von chorn (25.07.2011 um 18:35 Uhr) |
Sponsored Links |
|
||||
Erst mal Danke, die Diskussion ist richtig gut.
Aber, wenn ich mir das so recht zusammen reime, dann komme ich zum Schluss, dass es eine Software Frage ist. Folgerung: Der Kaffeetrinker öffnet eine Anfrage an die Datenbank mit "exclusive" Zugriff. Erst jetzt übernimmt die Datenbank und verhindern ein Verändern der Daten, solange bis der Kaffeetrinker seinen Becher geleert (gespeichert) hat. Fazit: Die Software muss die Anfrage richtig stellen und alle Eventualitäten eines zweiten/dritten oder vierten Zurgriffs abfangen. Die Integrität der Daten übernimmt die Datenbank. Komplex wird das Ganze wahrscheinlich genau in dem Augenblick wenn mehrere Datentabellen voneinander abhängig sind, beziehungsweise die ganze Datenbank im "exclusive" Zugriff gesetzt werden muss. Sehr komplex das Ganze
__________________
Personal stuff |
Sponsored Links |
Themen-Optionen | |
Ansicht | |
|
|
Ähnliche Themen | ||||
Thema | Autor | Forum | Antworten | Letzter Beitrag |
Problem mit Text neben Navigationsleiste | andi01 | CSS | 6 | 08.06.2011 17:54 |
HTML mit PHP Code aus Datenbank auslesen + ausführen | Garlandt | Serveradministration und serverseitige Scripte | 14 | 01.05.2011 13:45 |
Mitwachsender Content und Footer Problem | Bentham | CSS | 5 | 19.09.2010 12:49 |
IE 7: Zoom Problem, Höhen Problem, Text problem | Cu Chullain | CSS | 4 | 02.09.2010 14:56 |
Problem mit Background-Color im FireFox | to.ni | CSS | 2 | 31.08.2004 12:13 |