Objekte, Tabellen und wie die beiden zueinander finden

[nucknuck]

Erstmal ein „Hallo“ an alle die Zeit haben sich das hier durchzulesen

Wie hoffentlich der Titel schon sagt, dreht’s sich hier um C++ Objekte, die mit Hilfe einer Datenbank gespeichert werden sollen(MySQL).
Zu dem Thema gibt’s ja ein paar kommerzielle Produkte, die ich mir aber momentan nicht leisten kann.
Daher würde es mich interessieren, wie ihr dieses Problem angehen würdet oder vielleicht sogar schon angegangen habt?!
Existieren dazu Entwurfsmuster? Wenn ja, welche habt ihr schon erfolgreich eingesetzt?

Vielleicht hat ja jemand von euch einen guten Tipp für mich, wie ich das geschickt lösen könnte.

PS: Danke für's Lesen

[CStoll]

Nur mal ein paar spontane Gedanken:

Ein einzelnes Objekt wirst du wohl kaum in einer Datenbank ablegen wollen, also hast du vermutlich einen ganzen Haufen von Objekten (in irgendeinem Container gelagert), richtig? Dann würde ich diesen Container einer DB-Tabelle zuordnen (die Spalten der Tabelle entsprechen den relevanten Attributen deiner Objekte) und die Objekte jeweils als Datensätze dort eintragen (und wieder auslesen).

[nucknuck]

Genau.
Es ist unwarscheinlich, das ich nur ein einzelnes Objekt speichern werden.
Es existieren Objekte mit verschiedenen Typen. Für jeden Typ werde ich wohl eine zuständigen Klasse scheiben müssen, die den genauen Typ, der gespeichert werden soll, kennt.
Oft sind Objekte untereinander mittels Pointer verknüpft.
Damit ich nicht direkt alle Objekte laden muss, die mit meinem gespeicherten Objekt verbunden sind, werde ich das wohl über einen Proxy regeln müssen.
Der kann mir die Objekte dann laden, wenn sie wirklich benötigt werden.

Ich suche nach einem Muster, mit dem ich diese immer wiederkehrende Aufgabe recht leicht erschlagen kann.
Dazu hab ich mir mal das "Persistence Framework" von Larman angesehen.
Kennt das jemand?

[Artchi]

Wie du selber schon festgestellt hast, existieren diverse Produkte und die kosten Geld. Und diese kosten aus ganz bestimmten Grund Geld. Weil das selber machen wahrscheinlich teurer (Arbeitszeit und Nerven) kommt als wenn man das Produkt einmal kauft.

Es gibt aber auch eine kostenlose OO-DB, wie EyeDB. Diese ist aber leider auf Unix- und Linux-Server beschränkt (nix mit Windows). Cache ist auch cool, und ist sogar recht günstig, wenn man kommerziell was machen will.

Wenn du eine RDBMS benutzen willst, bräuchte man idealerweise ein O/R-Mappingtool. Kostenlose O/R-Mappingtools gibt es aber für C++ glaube ich nicht.

Wie macht man sowas? Da ist viel Handarbeit nötigm, wenn kein Tool/Lib da ist. Am einfachsten ist es, wenn man z.B. jedes Klasse auf eine Tabelle abbildet. Und jedes Attribit in eine Tab-Spalte packt. Halt O/R-Mapping...

Und dann einfach den Code dazu schreiben.

O/R ist leider immer doof. Ich favorisiere ja immer noch OODBMS, aber die wollen sich einfach nicht in der OO-Welt durchsetzen.

[Marc++us]

Für das sture O/R-Mapping gibt es zwei Ansätze.

Nehmen wir an, wir haben in einem Container folgende Konstellation:

container<oberklasse*>
class A : oberklasse;
class B : oberklasse;
// A und B unterscheiden sich in Attributen - ist der Unterschied nur in Methoden, macht das für die DB keinen Unterschied.

Variante 1)

In der DB legt man für den Container 2 Tabellen an - eine für die Klasse A und eine für die Klasse B, da natürlich jede Klasse eigene Attribute hat. Nun mappt man alle Objekte von A in die Tabelle A, und genauso für B.

Variante 2)

In der DB legt man für den Container 3 Tabellen an - eine für die Oberklasse, eine für die zusätzlichen Attribute von A, und eine für die zusätzlichen Attribute von B. Ein Objekt der Klasse A wird also in die Tabelle Oberklasse und die Tabelle A geschrieben, analog für B. Die eindeutige Objekt-ID bekommt die Oberklassen-Tabelle, und wird in den Tabellen A und B ebenso benutzt. Damit kann man die Tabelle Oberklasse durchlaufen und damit den gemeinsamen Anteil ermitteln, aber auch über die Objekt-ID auf die Attribute von A und B kommen. Natürlich muß in der Oberklassen-ID auch gespeichert werden, welcher Typ vorliegt, man muß ja wissen, in welche Tabelle (A oder man reinschauen muß.

Variante 2 hat offensichtliche Vorteile, wenn man häufiger über die Gemeinsamkeiten geht, und es ist bei A) schwierig zu sortieren. Hat man aber eher Zugriffe über die Unterschiedlichen Klassen, so kann A) geeigneter sein.

Das ist so ein Grundansatz als Idee.

[nucknuck]

Marc++us schrieb:

Variante 2)

In der DB legt man für den Container 3 Tabellen an - eine für die Oberklasse, eine für die zusätzlichen Attribute von A, und eine für die zusätzlichen Attribute von B. Ein Objekt der Klasse A wird also in die Tabelle Oberklasse und die Tabelle A geschrieben, analog für B. Die eindeutige Objekt-ID bekommt die Oberklassen-Tabelle, und wird in den Tabellen A und B ebenso benutzt. Damit kann man die Tabelle Oberklasse durchlaufen und damit den gemeinsamen Anteil ermitteln, aber auch über die Objekt-ID auf die Attribute von A und B kommen. Natürlich muß in der Oberklassen-ID auch gespeichert werden, welcher Typ vorliegt, man muß ja wissen, in welche Tabelle (A oder man reinschauen muß.

Ja, so oder zumindest so ähnlich hatte ich mir das auch gedacht.
Zusätzlich hab ich mir das Buch von Frau Prof. Balzert (Lehrbuch der Objektmodellierung) angesehen und dort war die Rede von dem Database Broker Pattern.
Das ganze funktioniert dort über drei Schichten:

1. Abstrakter Broker
Definiert die Algorithmen zum Laden und Speichern mittels Schablonenmethoden-Muster

2. Datenbank Broker
Stellt den Zugriff auf die Datenbank her und kümmert sich um die SQL Anfragen

3. Fachkonzept Broker
- Erzeugt das Fachobjekt aus den Daten des Datenbank Brokers.

In diesem Pattern werden alle Objekte an Hand der ObjektID geladen oder gespeichert. Klar, wenn ich die ObjektID hab, dann finde ich auch mein Objekt in der Datenbank.
Falls mir jedoch nur andere Eigenschaften bekannt sind, müßte ich ja zuerst die ObjektID ermitteln und dann das Objekt mit Hilfe der ObjektID komplett laden.
Wenn ich aber schon dabei bin die ObjektID zu ermitteln, kann ich mir auch direkt die anderen Eigenschaften des Objekts liefern lassen. Dann brauche ich ja keine Broker Klassen.

Hoffentlich hab ich mich einigermaßen verständlich ausgedrückt und euch ist klar, wie mein Problem aussieht.