Klassendesign und Logik

[stOrM]

Zitat von Schokohase:

Zitat von Ghostwalker:

Zitat von Schokohase:

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.

Diesen Fall wird es nicht geben, da der Anwendungsfall so simple sein wird, dass nur eine Person Daten ändert, also muss ich mir darüber keinen Kopf machen. Also keine Multiuserproblematik.
Was die Menge der Felder in den Tabellen angeht, mal so mal so, manche sind von der Menge her sehr klein, manche gehen Richtung 40 Felder und mehr, deshalb kam bei mir die Frage auf, direkt alles updaten oder irgendwo zwischen speichern, welche Felder ein Update benötigen.