Klassendesign und Logik

[stOrM]

Zitat:

Zitat von Schokohase (Beitrag 1426875)

Zitat:

Zitat von Ghostwalker (Beitrag 1426868)

Zitat:

Zitat von Schokohase (Beitrag 1426836)

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.

[MyRealName]

Wenn es professionell eingesetzt wird, kann man da aufg fertige Lösungen setzen, TMS Aurelius kommt da zum Bsp. in Frage. Auch DevArt hat ein ORM framework.

Zumindest bei TMS weiss ich, dass es genau sowas macht, du hast Klassen, die die Tabellen darstellen und du brauchst dich um die DB Sachen nicht zu kümmern. Du lässt dir erzeugte Objecte oder Object-Listen geben und bearbeitest die und wenn du willst, werden sie dann gespeichert

[ConstantGardener]

Kommt natürlich auch drauf an ob du mit einer Embedded Datenbank oder einem Server im Netzwerk arbeitest. Bei der EmbeddedDB kannst du wahrscheinlich ohne Not alle Felder im Update haben. Beim Server produzierst du viel Traffic und das dauert dann schon etwas länger.

[stOrM]

Zitat:

Zitat von ConstantGardener (Beitrag 1426941)

Kommt natürlich auch drauf an ob du mit einer Embedded Datenbank oder einem Server im Netzwerk arbeitest. Bei der EmbeddedDB kannst du wahrscheinlich ohne Not alle Felder im Update haben. Beim Server produzierst du viel Traffic und das dauert dann schon etwas länger.

SQLite vermutlich... Da es eher in Richtung privates Projekt geht, kommen kommerzielle Komponenten / Frameworks nicht in Frage werde ich aber mal im Hinterkopf behalten für ggf. andere Projekte.

[ConstantGardener]

....schau dir evtl. mal NEXUSDB an. Gibt es über GetIt in der Embedded Version kostenlos. Kompiliert mit in die EXE und hat SQL usw.

[Ghostwalker]

Zitat:

Zitat von Schokohase (Beitrag 1426875)

Zitat:

Zitat von Ghostwalker (Beitrag 1426868)

Zitat:

Zitat von Schokohase (Beitrag 1426836)

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.