Objekte und relationale Daten in einer Datenbank

13.02.06 - .NET, Datenverwaltung
Beitrag von Norbert Eder

Auf die Beiträge von Thomas und meiner Wenigkeit hat sich auch Alex zu Wort gemeldet. Sein Ansatz (angelehnt an den Microsoft SQL Server 2005) verfolgt das Ablegen von Objekten und relationalen Daten ein einer einzigen DB.

Auch hierzu ein paar Gedanken von mir:

Prinzipiell gibt es den Ansatz der ORDBMS (Objektrelationale Datenbank Management Systeme). Dabei wird ein relationales System um objektorientierte Fähigkeiten erweitert. Oft wird auch nur ein objektorientierte Zugriffsschicht darüberlegt. In der Tat werden allerdings keine Objekte mit relationalen Daten vermischt.

Wie würde das Speichern von Objekten zusammen mit relationalen Daten in einer Datenbank in der Praxis aussehen?

Prinzipiell stehe ich dem Vermischen von Objekten mit relationalen Daten eher negativ gegenüber. Der Ansatz von XML-Feldern in einer Datenbank (siehe SQL Server 2005) ist durchaus praktisch und in manchen Fällen auch sinnvoll. Dies jedoch zu nutzen, um Objekte abzulegen macht eher weniger Sinn. Aus folgenden Gründen (wenn ich von Serialisierung spreche, beziehe ich mich auf die XML-Serialisierung):

- Aufwand der Serialisierung. Bedingt durch diesen Aufwand können die Daten ohnehin wieder in eine relationale Struktur gequetscht werden. Performancemässig wird es hier (allerdings hab ich das jetzt nicht getestet) nicht sehr viel Unterschied geben.

- Weiters verleitet dieser Ansatz dazu, eine Tabelle mit mehreren XML-Feldern zu erstellen und darin serialisierte Objekte abzulegen. Eventuell noch von unterschiedlichen Typen. Spätestens dieser Punkt würde durchaus Probleme aufwerfen.

- Durch das einfache serialisierte Ablegen würden in der Datenbank Referenzen nicht mehr ersichtlich sein. In einem reinen relationalen oder reinen objektorientierten System bleibt dieser Vorteil erhalten. Referenzen in XML sind zwar möglich, aber selbst bei einem eigenen XML-Serializer nützt das Einfügen dieser Referenzen wenig, wenn sie durch die Datenbank nicht dargestellt werden können.

Abfragen sind natürlich auch in dieser Form noch auf der Datenbank möglich ohne alle Daten zu laden, aber durch die Vermischung von SQL und XPATH etc. würde ich meinen, dass der Performance-Vorteil eher gering ausfällt -> dürfte wohl im Minusbereich angesiedelt sein.

Und zu guter Letzt: Diese Variante würde kein gemeinsames Ablegen von Objekten und relationalen Daten implizieren. Das einzige was Sinn machen würde, wäre das Ablegen von relationalen Informationen (Metdaten etc.) zu Objekten - aber ich denke das übernimmt ohnehin die Indizierung für uns.

Soweit mal meine ersten Gedanken dazu. Weitere werden vermutlich noch folgen, wenn ich allen "neuen" Gedanken nachgegangen bin ;-)

Daniel

15.02.06

	Ich habe vor kurzem im Rahmen eines kleineren Projekts NHibernate ausprobiert (Hibernate für .NET) und war doch recht positiv angetan. Was hältst du davon?

Norbert

15.02.06

	NHibernate ist kein OODBMS oder ORDBMS, sondern nur ein O/R-Mapper. Das heißt dieses Framework wandelt Objekte in eine relationale Struktur um und wieder zurück. Prinzipiell ist (N)Hibernate nicht so schlecht, ich verwende aber meinen eigenen DAL. Dies hat den Vorteil, dass er auf meine Bedürfnisse zugeschnitten ist.

bart

16.01.08

	Nun stellt sich doch die Frage, wann es sinnvoll ist, einen OR-Mapper zu benutzen und wann eine ORDB?

Kommentar hinzufügen

Bitte das Formular ausfüllen, um Deinen Kommentar hinzuzufügen.