Zitat von
s.h.a.r.k:
Gut, das ist nicht schlecht zu wissen, da ich bisher nicht all zu viel über Datenbanken und die dahinter steckenden Prinzipien weiß. Ich nutze sie halt!
Jetzt stellt sich mir halt die Frage, wie du das sinnvoll umsetzen würdest?!
Denn es macht meines Erachtens nach keinen Sinn, jeden Benutzer gleichzeitig auf die Daten zugreifen, diese ändern und dann, wenn er es speichern will, ihm eine Nachricht zukommen zu lassen, dass leider schon ein anderer Benutzer die Daten geändert hat. Das finde ich nicht sehr sinnig... Ich weiß nur nicht, wie ich das sonst machen will?
Was heisst leider schon? Das passiert halt ab und zu mal. Ich meine - Du musst ihn ja nicht warnen. Es geht auch anders: Der, der zuletzt die Daten ändern überschreibt die Änderung des zuvorgehenden. Der letzte gewinnt sozusagen. Das ist das gleiche Prinzip, wie Du es auch hast, wenn mehrere Leute an einer Datei im Netz arbeiten. Nur guckt dann halt der Erste in die Röhre, dessen Änderungen überschrieben werden.
Diese Information: "Die Daten wurden schon verändert (Anzeige der neuen Daten): Wollen Sie ihre Änderung wirklich speichern oder nochmal bearbeiten?" ist a) Benutzerfreundlich und b) einfach the right way to do it.
Genau das erwartet der Benutzer auch von einer Anwendung.
Auf der anderen Seite musst Du Dir die Frage gefallen lassen, wie oft dieser Fall wirklich vorkommen wird. In einer Buchhaltungssoftware mit 50+ Benutzern hatten wir solche Fälle mal zu statistischen Zwecken mitprotokolliert. Zu solchen Kollisionen kam es maximal 3 mal pro Woche. Wie gesagt: 50 Benutzer, die alle gleichzeitig auf der Datenbank waren.
Zitat von
s.h.a.r.k:
Bzgl dem sperren einzelner Datensätze: den Absturz eines Clients (sei es ein Systemabsturz oder einfache Trennung vom Netz) habe ich durchaus berücksichtigt und hatte vor, jede Nacht um 12 Uhr (da arbeitet mit Sicherheit keiner mehr an den Daten) aller Verbindungen zu trennen und alle Daten wieder freizugeben.
Wir reden hier von ganzen Table-Locks. Gleich dem ersten Benutzer passiert das um halb neun Uhr morgens. Das heisst der Rest der Belegschaft darf dann heimgehen und morgen wiederkommen. Gut, die Datenbank wird den Lock irgendwann austimen lassen, das heisst je nach Konfiguration dürfen die Kollegen schon nach einer halben Stunde weiterarbeiten und den Datensatz selber sperren.
Aber was, wenn User A einen Datensatz öffnet, diesen damit sperrt, und dann einen dringenden Anruf bekommt. Noch schnell was erledigen muss, dabei aufgehalten wird.. und Du hast auf einmal über 3 Stunden einen Table-Lock auf (weil der noch seinen Rechner sperrt und die Applikation schön im Hintergrund seine Tabelle gesperrt hält) und derweil kann kein anderer User auf dieser Tabelle arbeiten...
Vergiss das manuelle Locking. Es ist zwar möglich, aber nur in extrem wenigen Ausnahmefällen wirklich Sinnvoll.