eine Frage zum Verständnis (2 Clients -> ein Datensatz)

[C-Bär]

Mal angenommen eine Tabelle enthält zu jedem Auto ein Feld mit der Reparaturhistorie. Auf diese Tabelle haben mehrere Clients gleichzeitigen Zugriff.
Weiter angenommen, zwei Clients rufen den Datensatz 'Rotes_Auto' auf. Client A schreibt "Zündkerzen gewechselt" in das Feld und speichert. Client B schreibt "Anlasser getausch" rein und speichert.
Dadurch geht aber der Eintrag "Zündkerzen gewechselt" verloren.
Wie kann man dieses Problem umgehen? Unmittelbar vor dem speichern den Datensatz noch mal laden geht ja wohl nur wenn`s nur wenige Clients gibt.

C-Bär

[RED-BARON]

Du hast doch 2 Tabellen, z.B. Fahrzeuge und Wartung, oder ?

Jeder Client erzeugt einen neuen Eintrag in der Tabelle "Wartung".

Da löscht/überschreibt sich nix gegenseitig.

Problematischer würde es sein, wenn die Fahrzeugstammdaten geändert
werden würden. In dem Fall muss halt dafür gesorgt werden, dass nur
ein Client den Datensatz mit Schreibrechten bekommt.

[hustbaer]

Wie kann man dieses Problem umgehen? Unmittelbar vor dem speichern den Datensatz noch mal laden geht ja wohl nur wenn`s nur wenige Clients gibt.

also ...
erstmal, wenn du das in einer transaktion machst, dann geht das genau so.
also...

1. transaktion: daten laden + anzeigen + transaktion committen

2. daten dem user zeigen und editieren lassen

3. transaktion:
3.1: daten laden und mit den original-daten vergleichen.
3.2: wenn ungleich -> fehler. wenn gleich, daten überschreiben.
3.3: dann transaktion committen

die transaktion stellt dabei sicher, dass schritt 3 NICHT "unterbrochen" werden kann, d.h. es kann kein anderer die daten zwischen 3.1 und 3.3 geändert haben.

diese technik kann man auch verwenden, um z.b. die von RED-BARON erwähnten stammdaten zu ändern, OHNE langfristig einen lock zu halten.

aber.

wieso überhaupt daten ändern?
normalerweise löst man das so, dass für jeden vorgang der in der history gespeichert werden soll, eine eigene zeile eingefügt wird. dadurch kann nie irgendwas überschrieben werden, weil alles nur INSERTs sind.

(das ist das was RED-BARON auch meint, nochmal mit anderen worten)

[C-Bär]

dankeschön für Eure Antworten.
Manchmal kommt man nicht auf die einfachsten Sachen.
Klar!, einfach zwei Tabellen anlegen.

C-Bär

[Cpp_Junky]

Der beschriebene Vorgang würde auf den meissten Datenbank-Systemen so auch gar nicht funktionieren. Der würde beim Speichern gleich einen Concurrency Error rausschmeissen und User B müsste den Datensatz neu laden oder abbrechen.

[hustbaer]

Cpp_Junky schrieb:

Der beschriebene Vorgang würde auf den meissten Datenbank-Systemen so auch gar nicht funktionieren. Der würde beim Speichern gleich einen Concurrency Error rausschmeissen und User B müsste den Datensatz neu laden oder abbrechen.

würde er nicht, wenn man zwei getrennte transaktionen verwendet. eine zum laden der daten, und eine zweite wenn der user auf "apply" drückt.

was man üblicherweise so macht.

grund: der user kann sich beliebig lange zeit lassen, bis er die geänderten daten "speichert", und man will normalerweise vermeiden transaktionen für lange zeit offen zu halten.