Objektorientierte Datenbanken und Delphi ?

[Eugen Kludt]

Hallo,

ich möchte eine Datebank entwickeln, die für mich eine Karteisammlung ersetzt. Da ich Delphi kenne, hab ich es zuerst mit einer relationalen Datenbank versucht (Access + Delphi) und dabei festgestellt, daß es nicht die optimale Lösung dafür sein kann. Ich vermute daß ein objektorientierter Ansatz für mich einfacher und übersichtlicher wäre.
Nach schneller Durchsicht einiger Bücher zu diesen Thema hab ich kein Buch gefunden daß Delphi erwähnt und ich möchte nicht auf Java oder C++ umsteigen.
Hab ich in Delphi überhaupt die Möglichkeit irgendwas außerhalb der relationalen Datenbank zu entwickeln ?

[Frank Ambiel]

Hallo Eugen,

was verstehst du unter einer objektorientierten Datenbank ?

Gruss

Fran

[Eugen Kludt]

Hi,

unter der objektorientierten Datenbank, verstehe ich eine Datenbank die aus komplexen Objekten aufgebaut ist, deren Attribute selbst Objekte sein können (z.B. Listen oder Mengen).
Ich hab mit einer Bücherdatenbank angefangen, und sofort festgestellt, daß eine Liste aus mehreren Autoren Probleme bereitet, da ich keine Listen benutzen konnte. Mittlerweile hab ich rausgefunden wie es funktioniert, nur ist es mit einer zusätzlichen Tabelle unnötig umständlich. Außerdem brauche ich Querverweise zwischen den einzelnen Eintragungen, und bekomme so eine Unmenge an Tabellen, mit vergleichsweise wenig Inhalt.
Als weiteres wäre interessant wenn Vererbung und Polymorphismus auch innerhalb der Datenbank funktionieren würden.

ich hab zwei Bücher zu objektorientierten Datenbanken gefunden:

Objektorientierte Datenbanken (ISBN 3-89319-800-8) http://wwwdb.informatik.uni-rostock.de/baeren/
und
Objektorientierte und objektrelationale Datenbanken (ISBN 3-932588-68-1).

Dort werden z.B. GemStone, ObjectStore, Versant als objektorientierte, und Oracle8i, UniSQL/X als Objektrelationale Datenbankprodukte bezeichnet. Diese Produkte sollen auch nur Java, C++ und XML Anbindung besitzen. Obwohl die Bücher relativ neu sind (1997 und 2000) ist Delphi mit keinem Wort erwähnt (zumindest habe ich es nicht gefunden).
Wieso das so ist, kann ich nicht nachvollziehen. Es hat mich aber abgeschreckt. Denn wenn diese Datenbanken Delphi nicht unterstützen, ist es für mich einfacher umständlich mit Access und Tabellen zu arbeiten, als auf Java umzusteigen

[Klaus-Peter Fitzner]

Hallo Eugen,
eine Beziehung zwischen Büchern und Autoren wird immer eine n:m - Beziehung sein. Diese macht natürlich eine neue Datei zwingend erforderlich.

mfg Klaus-Pete

[Gesine Kuhlmann]

Hi,

Sobald man das Universitätsgelände verlässt, spielen Objektorientierte Datenbanken keine Rolle mehr. ;-) Ob die wenigen, die tatsächlich erhältlich sind, auch noch das Entwicklungswerkzeug der eigenen Wahl unterstützen, muss man vorher natürlich klären. Selbst wenn man einen Anbieter findet, der eine Anbindung verspricht, muss man sich im Klaren darüber sein, dass OO-DB's noch in den Kinderschuhen stecken. Das wird auch noch lange so bleiben, denn bisher konnte keiner den gravierenden Vorteil der Objektorientierung auf DB-Ebene klar machen. Zumal Datensätze in relationalen Systemen im Prinzip auch als Objekte betrachtet werden können, was wiederum zu so idiotischen Bezeichnungen wie <i>objektrelational</i> führt.

Also tu dir selbst 'nen Gefallen und modelliere deine Daten auf einer IB-Datenbank.

Gruß
Gesin

[Andreas Kosch]

Hallo,

abgesehen davon, ob objektorientierte Datenbanken sinnvoll sind oder nicht, unterstützt Delphi ab der Version 4 (wenn ich mich richtig erinnere) die sogenannten <b>Nested DataSets</b> (die o.g. ORACLE-Implementierung). Eine Spalte der Ergebnismenge einer Abfrage kann somit aus einer kompletten Tabelle besteht, im Demos-Verzeichnisbaum von Delphi ist ein Beispiel, dass diesen Effekt demonstriert: <br>
a) TDBGrid zeigt den Button ... (3 Punkte) in der Spalte an, <br>
b) mit dem Anklicken dieses Buttons "springt" ein zweiten TDBGrid mit den Inhalt dieser eingebetteten Datenmenge auf.

Auch ADO (und damit ADO Express) unterstützt mit dem SHAPE-Provider so etwas ähnliches:
<pre>
SHAPE {SELECT * FROM Customers}
APPEND ({SELECT * FROM Orders}
RELATE CustomerID TO CustomerID)
</pre>
Der "Vorteil" der ORACLE 8i liegt nur darin, dass der Entwickler die separaten Tabellen nicht mehr explizit einzeln deklarieren muss, aber intern arbeitet die Datenbank noch nach dem alten (aber dafür seit langem bewährten) Prinzip.
&#10

[Eugen Kludt]

Hallo,

vielen Dank für die Antworten und besonders für den Ratschlag. Dieser hat meine Bedenken ausgeräumt

mit freundlichen Grüßen
Eugen Klud