Das hat doch mit dem Umfang der Tabellen nichts zu tun, sondern mit dem Kontext, bzw. wie du Kollisionen entdecken kannst.
Öhm...dafür gibts sowas wie PrimaryKeys bzw. Unique index, um einen DS eindeutig zu identifizieren. Dein Beispiel läst sich mit einer Plausibilitätsprüfung vermeiden, und hat an und für sich nix mit der
DB zu tun.
Dann hast du mich nicht verstanden.
Der Datensatz mit der ID 1 wird von zwei Benutzern gleichzeitig so wie beschrieben verändert. Wenn jetzt nur die Änderungen der Benutzer gespeichert werden, dann kommt dieser Unsinn heraus.
Soweit schon richtig, aber das ist unabhängig davon, ob ich nun im Update den gesamten Datensatz wegspeicher oder nur die geänderten Felder. Wie schon gesagt muß das die Eingabeprüfung abfangen, nicht die
DB.