OO vs relationalem Datenmodell

SQL, Dateimanagement - Sprachunabhängige Datenhaltung
Antworten
MrTiger
Beiträge: 28
Registriert: Sa Aug 11, 2012 10:44 pm

OO vs relationalem Datenmodell

Beitrag von MrTiger » Di Aug 27, 2013 11:30 pm

Hallo

Ich habe ein kleines Anliegen bezüglich Objekt orientierten und relationalen (SQL etc.) Datenmodellen.

Ich überlege mir gerade ein Beispiel wo das OO Datenmodell besser geeignet ist als das relationale und ein anderes Beispiel wo das relationale besser geeignet ist, aber ich komme irgendwie auf keinen grünen Zweig.

Fallen vielleicht jemandem gerade solche Beispiele ein?

Die Hauptanwendung von Objekt Datenbanken ist ja, Programmiersprachen persistent zu machen, d.h. Objekte zu konservieren. Was gibt es sonst noch für Anwendungen? Also im Sinne von Generalisierungen.

Benutzeravatar
cloidnerux
Moderator
Beiträge: 3079
Registriert: Fr Sep 26, 2008 4:37 pm
Wohnort: Ram (Gibts wirklich)

Re: OO vs relationalem Datenmodell

Beitrag von cloidnerux » Mi Aug 28, 2013 7:53 am

Ich überlege mir gerade ein Beispiel wo das OO Datenmodell besser geeignet ist als das relationale und ein anderes Beispiel wo das relationale besser geeignet ist, aber ich komme irgendwie auf keinen grünen Zweig.

Fallen vielleicht jemandem gerade solche Beispiele ein?

Die Hauptanwendung von Objekt Datenbanken ist ja, Programmiersprachen persistent zu machen, d.h. Objekte zu konservieren. Was gibt es sonst noch für Anwendungen? Also im Sinne von Generalisierungen.
Datenhaltung zu Generalisieren fällt auch mir nicht leicht.
Generell ist es ja so, dass beide Systeme von den Möglichkeiten her gleichwertig sind, doch immer für die Anwendung unterschiedliche Vorteile bergen.
Neben den systematischen Abwägungen ist es natürlich die Frage der Anwendung. Arbeitest du mit sehr komplexen Daten, die in einer SQL-Datenbank mitunter viele JOINs und komplexe SQL-Abfragen erfordern, ist es mitunter sehr viel Sinnvoller, auf eine ODBMS umzusteigen.
Der Vorteil liegt einfach nur für dich als Entwickler, dass du direkt Objekte in eine DB speichern und wieder lesen kannst, du damit also deine Software in einer OO-Sprache direkt mit Daten füttern kannst, ohne sie vorher erst zu verarbeiten und an deine Klassen anzupassen.

Ich persönlich habe bisher noch kaum mit ODBMS gearbeitet sondern hauptsächlich mit MySQL oder SQLite, von daher bin ich nicht der Richtige eine solche Frage umfassend zu beantworten.
Redundanz macht wiederholen unnötig.
quod erat expectandum

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8470
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: OO vs relationalem Datenmodell

Beitrag von Xin » Mi Aug 28, 2013 9:24 am

MrTiger hat geschrieben:Ich habe ein kleines Anliegen bezüglich Objekt orientierten und relationalen (SQL etc.) Datenmodellen.

Ich überlege mir gerade ein Beispiel wo das OO Datenmodell besser geeignet ist als das relationale und ein anderes Beispiel wo das relationale besser geeignet ist, aber ich komme irgendwie auf keinen grünen Zweig.
Vorweg, ich habe noch nie mit einem Objektorientierten Datenbanksystem gearbeitet. Der Anwendungsfall hat sich für mich nie ergeben.


Die Idee eines OODBMS ist ja, dass Daten direkt in der Datenbank manipuliert werden. Das bedeutet, dass man ganze Objekte in die Datenbank ablegt samt der Methoden, wie man sie manipuliert. Man kann ein Datum also direkt in der Datenbank verändern, indem man eine Methode der Klasse bezogen auf ein bestimmtes Objekt ruft.
Bei einer relationalen Datenbank muss man den Datensatz vom Server laden, manipulieren und wieder zum Server wegschreiben.

Das OODMS bildet in dem Fall also bereits die Logik und die Datenhaltung ab, also alles, was bei einem normalen Programm im Arbeitsspeicher liegt.
MrTiger hat geschrieben:Fallen vielleicht jemandem gerade solche Beispiele ein?

Die Hauptanwendung von Objekt Datenbanken ist ja, Programmiersprachen persistent zu machen, d.h. Objekte zu konservieren. Was gibt es sonst noch für Anwendungen? Also im Sinne von Generalisierungen.
Datenbanken werden in der Regel dazu genutzt, effizient sehr viele Daten zu speichern ("Big Data") und aus diesen Datenmengen einzelne Daten zu filtern. Dafür eignen sich Tabellen sehr gut. Eine Zeile in einer Tabelle ist ein Objekt, aber jede Zeile in einer Tabelle ist unabhängig von allen anderen Zeilen (von der Behauptung(!), dass Spalten einen gültigen Foreign Key darstellen mal abgesehen). Bei einer Objektdatenbank würde das gewissermaßen einem Array von Objekten entsprechen.

Die Idee hinter einer OODBMS ist aber, Objekte direkt in der Datenbank zu ändern. Speichert man beispielsweise ein Bild, so könnte die Datenbank eine DrawLine-Methode anbieten, die beschreibt, wie man das Bild in der Datenbank verändert. Um das Bild zu erreichen müsste man sich aber - wie im Arbeitsspeicher - durch die Objekte hangeln. Möchte man alle Avatare einer Userdatenbank mit einer Linie durchkreuzen, muss man durch die Liste der User laufen, und dort die Avatare auffordern, sich mit einer Linie zu durchkreuzen. Keine übliche Anwendung.

Übliche Anwendungen wären alle User zu suchen, die z.B. mehr als 1000 Postings gemacht haben. Das müsste man programmieren. Für eine relationale Datenbank ist das ein einfacher SQL-Befehl und es ist ein üblicher SQL-Befehl, das bedeutet, die DBMS-Entwickler haben sich da wirklich Mühe gegeben, das hochgradig zu optimieren. Für den DBMS-Benutzer ist ein "SELECT * FROM User WHERE Postings >= 1000" auch schneller programmiert, als eine Methode für das Datenbankobjekt "Forum", dass dann über die Liste der User iteriert.

Tabellen zu durchlaufen ist einfach naheliegender, wenn man Daten sucht, als in der (Abbildung der) realen Welt alle Räume zu durchsuchen. Entsprechend sind SQL-Datenbanken eine Vereinfachung, keine eindeutige klare Abbildung der realen Welt, also eigentlich ein wenig gepfuscht, aber dafür lösen sie das Problem die richtigen Daten unter einem Wust von Daten zu finden, etwas einfacher.
SELECT * FROM Heuhaufen WHERE itemtype = 'Nadel' ist nunmal einfacher, als zu beschreiben, was ein Heuhaufen ist und jedes Element einzeln anfassen zu müssen. Eine Tabelle reicht, um jedes Element des Heuhaufens aufzulisten. ;-)

Dafür kannst Du Objekte/Zeilen halt nicht In-Place ändern. Das Bild müsstest Du aus der SQL-Datenbank laden, selbst modifizieren und dann wieder hochladen.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

Antworten