Objekte in Datenbank speichern und parallel zugreifen

[stahli]

Hallo alle,

in meinem aktuellen Projekt verwende ich Datenobjekte zur Datenverwaltung und sichtbare Objekte zur Anzeige und Bearbeitung der Daten. Die sichtbaren Objekte können sich bei "ihrem" Datenobjekt registrieren und ab sofort stehen die beiden ständig in Verbindung und tauschen die Daten miteinander aus. Die Speicherung der Daten erfolgt in einer spezialisierten Ini. Beim Laden der Datei werden die enthaltenen Objekte und Beziehungen wieder hergestellt.

Das funktioniert soweit auch ganz gut, aber ein Nachteil besteht darin, dass keine 2 Cilients gleichzeitig auf die Daten zugreifen können und in bestimmten Fällen nur eine Instanz der sichtbaren Objekte verwaltet werden kann.

Daher habe ich überlegt, die Daten doch in einer Datenbank zu speichern.

Darin müssen dann "komplette Objekte" gespeichert werden, incl. Position, Größe usw.
Dann müsste es sichtbare Komponenten geben, die sich aus dieser Datenbank versorgen und weitere sichbare Komponenten erzeugen.
Wird z.B. ein Positionswert in der Datenbank verändert, müsste das in allen angebunden Clients und deren sichtbaren Objekten beachtet werden.

Anbei habe ich einmal ein kleines vereinfachtes Testprojekt angehängt (es muss nur die DBE installiert sein). Man kann mehrere Instanzen des Programms starten. Wenn man die X/Y-Werte in der Datenbank ändert hat dies unmittelbar Auswirkungen auf alle Programme. Durch Verschieben einer Komponente werden die Positionsdaten in der Datenbank ebenfalls verändert und von den anderen Instanzen übernommen.

Natürlich fehlen da noch jede Menge Dinge an der Umsetzung, insbesondere, dass die Aktualisierungen nur für die Komponenten erfolgen, die von Änderungen in der DB betroffen sind usw.

Im weiteren Verlauf müssen dann auch die Anzahl und Art der Objekte gespeichert werden. Wenn man im Demoprogramm z.B. weitere unterschiedliche Objekte auf die "Designer" ziehen würde, müssten diese in der Datenbank komplett gespeichert (Klassenname, Position, Größe, Farbe etc.) und sich beim Neustart so wieder herstellen lassen.


Meine Frage aber schon einmal:
- Erfinde ich das Rad gerade neu?
- Gibt es dafür gängige Umsetzungen?
- Habt Ihr an einer solchen Lösung grundsätzlich Interesse?

Stahli

[mkinzler]

-Zerlegung der Objekte durch Normalisierung (z.B. jede Eigenschaft Eintrag in Tabelle)
oder
-Speicherung in BLOB

[Luckie]

Oder man nimmt eine objektbasierende Datenbank. Ist eigentlich eine sehr schöne Sache. db4o wäre eine Möglichkeit. Allerdings weiß ich nicht, in wie fern Delphi unterstützt wird.

[stahli]

Der Hintergrund meines Beitrags war eigentlich weniger wie und wo die Objekte gespeichert werden, sondern vielmehr dass eine Live-Verbindung zwischen dem bzw. den Programmen und den Daten in der DB bestehen bleibt.

Die Eigenschaften der Objekte sind quasi in eine DB "ausgelagert" und können von mehreren sichtbaren Objekten (sogar in verschiedenen Programminstanzen) parallel verwendet werden.

Wenn ich also (durch welche Aktion auch immer) den Spieler "André Stahl" in der DB in einer Liste von Position 10 auf Position 1 verschiebe (das kann durch eine Programmfunktion erfolgen oder durch händisches Verschieben eines Spielers in einer Programminstanz) werden in allen Programminstanzen und in allen sichtbaren Spielerlisten die Reihenfolge der sichtbaren Spieler sofort korrigiert.

In meinen Fall betrifft das eine Turnierverwaltung. Man könnte dann an zwei Computern am gleichen Turnier arbeiten (z.B. wenn es in zwei Hallen durchgeführt wird) und zwei weitere Computer als Auskunftssystem bereitstellen, indem die Spieler alle Daten live einsehen können, Änderungen aber nicht zugelassen werden (so als grundsätzliche Überlegung).

Für meine Zwecke hört sich das erst mal sehr interessant an und ich wollte wissen, ob da auch andere Interesse dran hätten...


Stahli

[generic]

Also ist eigentlich dein Problem, das du eine Info brauchst, wann sich etwas in der Datenbank geändert hat, damit der/die andere(n) Client(s) die Daten lesen können.

2 Möglichkeiten:
1) du baust dir einen Dienst welche die Daten verwaltet und den Clients dann "updates"-Schickt. Vielleicht per TCP/IP.
2) Du nimmst eine Datenbank welche dir Ereignisse schicken kann, damit die Clients dann die Daten pollen können. (z.B. Firebird)

Datenbanken sind übrigens dafür da, dass mehrere Clients gleichzeitig auf die Daten zugreifen können. Daher verstehe ich nicht ganz deine Aussage, dass das nicht geht.

[hanspeter]

Ich habe das in Firebird mit Events gelöst.
Datenbanktrigger reagieren auf Veränderungen und schicken einen Event an alle angeschlossenen Clients.
Die Clients melden an, welche Events sie erreichen sollen.
Damit muss nicht jeder auf jedes Event reagieren.

Da ich noch Clients habe, welche Probleme mit FB Events haben (Windows NT4.0), habe ich noch eine andere Lösung implementiert.

Ein Trigger schreibt in eine Eventtabelle Timestamp der letzten Änderung und die betroffene Tabelle, Datensatz.
Diese Infotabelle wird zyklisch abgefragt.
Mit einer storedprocedure geht das schneller als das Eventhandling.

Mein Programm hat übrigens exakt den gleichen Einsatzfall nur für eine andere Sportart.

Mit Gruß
Peter

[stahli]

1) Info an die Clients
Richtig, aber ich wollte das möglichst einfach halten, so dass es mit allen DB funktionieren würde. Es müsste lediglich ein Zugang zur DB bestehen, mehr nicht. Das könnte dann so laufen:
Die Clients melden sich "bei der Datenbank an" - ein Datensatz pro angebundenem Programm.
Bei Änderungen in der DB werden "Änderungsaufträge für jeden Client eingetragen:
Client1 -> Spieler23
Client2 -> Spieler23
Client1 -> Ergebnis125
Client2 -> Ergebnis125
Die Clients schauen dann zyklisch nach, ob sie etwas aktualisieren müssen, veranlassen ein Invalidate für die entsprechenden Komponenten und löschen den Änderungsauftrag in der DB (ganz grob halt).

2) Zu "normalen Datenbankanwendungen" wäre hier abweichend, dass abhängig von den Datensätzen der DB in den angebundenen Clients sichtbare Komponenten erzeugt, angeordnet, gezeichnet und gelöscht werden. Die DB-Inhalte werden nicht von DB-Komponenten angezeigt sondern das gesamte Formular wird abhängig von der DB aufgebaut und ständig an deren Einträge angepasst - eben auch auf mehren Rechnern parallel.

Ich will ja hier auch keine ellenlangen Diskussionen starten, hatte nur gedacht, dass das vielleicht auch andere interessieren könnte.

Stahli

Roter Kasten: @Peter
Genau so meine ich das auch, habe aber von vorn herein eine möglichst einfache Lösung im Auge, dann ist das von der verwendeten Datenbank möglichst unabhängig.
Schreib doch mal einen Link zu Deinem Programm, würde mich interessieren!

[hanspeter]

Zitat von stahli:

Schreib doch mal einen Link zu Deinem Programm, würde mich interessieren!

www.Autuvo.Com, dort unter "Was ist Autuvo"

Übrigens knapp 2,5 Mio Quellzeilen.

Gruß Peter

[shmia]

Mit dem üblichen 2-Tier Modell manövriert man sich bei diesen Anforderungen irgenwann in die Sackgasse.
Man braucht eben ein 3-Tier Modell.
Die Clients reden mit dem zentralen Applikationsserver.
Die Clients werden vom Applikationsserver über Änderungen benachrichtigt.
Der Applikationsserver lädt und speichert seine Daten aus/in eine Datenbank.

[stahli]

[OT]
Hallo Peter, danke für den Link. Sieht ja auch ganz schön umfangreich aus mit der Vernetzung etc.
So umfangreich wird es bei mir nicht werden (max. 2-3 PC´s), aber trotzdem werden viele Änderungen zu verwalten sein...
Gruß
André
[/OT]