Objektorientiertes Datenbankmodell

[konstantin]

Hallo Community!

Meine Frage hat zwar nur inderekt was man *BSD zu tun, ich hoffe aber, ihr seit mir deswegen nicht böse und habt eine Antwort parrat. ;-)

Gibt es (unter *BSD) ein Datenbanksystem, welches statt des "üblichen" Relationenmodells eine objektorientiertes Modell anbietet? Diese sollte natürlich mindestens kostenlos, am Besten sogar frei sein.

Würde mich halt nur mal interessieren, was es da so in der Praxis gibt und vielleicht auch ein wenig mit herumspielen.

Konstantin

 

[Astro]

OpenLDAP?

 

[k3rn3lpanic]

PostgreSQL ist zwar nicht komplett OO, aber zumindest Objektrelational.

Mehr Infos unter www.postgresql.org

Fuer richtig OO waeren vielleicht noch db4o und Speedo. Sind aber beides Java-basierte Loesungen, insofern fuer FreeBSD eventuell nicht unbedingt zu empfehlen.

 

[chaos]

Wirkt unter Zope nicht irgendwo eine OO-DB?

 

[steinlaus]

Wirkt unter Zope nicht irgendwo eine OO-DB?

Soweit ich weis "schimpft" sich die ZODB...

 

[k3rn3lpanic]

Hab ich vorhin ganz vergessen, wozu brauchst Du eine OO-DB wenn man fragen darf? Nur aus Interesse oder hat das einen ernsthaften Hintergrund?

 

[konstantin]

Hab ich vorhin ganz vergessen, wozu brauchst Du eine OO-DB wenn man fragen darf? Nur aus Interesse oder hat das einen ernsthaften Hintergrund?

Würde mich halt nur mal interessieren, was es da so in der Praxis gibt und vielleicht auch ein wenig mit herumspielen.

... ich dachte, das würde damit klar werden!

Nur aus reinem Interesse. Man hört ja immer von den verschiedenen Datenbankmodellen. Und da ich aus der Praxis nur relationale DBs kenne, wollte ich mir geren mal ein OO-DB angucken.

 

[kaishakunin]

db4o http://www.db4o.com/deutsch/Default.aspx?AspxAutoDetectCookieSupport=1

oder

ZODB http://www.thomas-guettler.de/vortraege/zodb/einfuehrung.html

existieren.

Allerdings sei angemerkt, das echte OODB eigentlich schon lange wieder tot sind. Es ist zwar ein netter Ansatz, hat sich in der Praxias aber nicht als praktikabel erwiesen, da im OO-Ansatz die Einfachheit der Relationenmodellierung fehlt.

Im Allgemeinen geht man heute davon aus das in Zukunft 80% der DB Objektrelational sein werden, nur Nischenlösungen werden auf OODBMS oder RDBMS setzen.

Was ntürlich nicht heißen soll, das man sich mit OODBMS beschäftigen kann, aber die Sau ist halt schon lange durchs Dorf getrieben worden und seit Mitte der 1990er tot.

Ansonsten kann ich nur PostgreSQL empfehlen, das ist *das* OpenSource DBMS der Zukunft. Für Embedded Devices evtl. noch Sleepycats Berkeley DB, aber die wurden grade von Oracle gekauft.

 

[kaishakunin]

... ich dachte, das würde damit klar werden!

Nur aus reinem Interesse. Man hört ja immer von den verschiedenen Datenbankmodellen. Und da ich aus der Praxis nur relationale DBs kenne, wollte ich mir geren mal ein OO-DB angucken.

Wie gesagt, für den ernsten EInsatz sind ORDBMS angesagt. Und daran wird sich auch so schnell nichts ändern.

 

[CAMISOLITE]

kaishakunin hat recht, OODBMS sind nicht wirklich am Markt präsent. Dafür ist objekt-relationales Mapping angesagt (siehe z.B. DB2 von IBM).

Ich muß gestehen, daß ich zwischen dem OO-Paradigma und dem Relationalem Datenmodell auch nicht unbedingt sooo viele Diskrepanzen sehe. Ich würde mal sagen, es ist eine unterschiedliche Sichtweise auf die selbe Sache. Die Modellierung ähnelt sich mitunter doch schon sehr.

PostgreSQL ist sicher eine gute Wahl.

 

[Azazyel]

Wie gesagt, für den ernsten EInsatz sind ORDBMS angesagt. Und daran wird sich auch so schnell nichts ändern.

Eines der Haupteinsatzgebiete für OODBMS ist CAD-Software, dort lässt sich das Datenmodell kaum in einer relationalen Datenbank abbilden, wofür sich die OODBMS-Hersteller auch fürstlich bezahlen lassen. Im Rest der Welt (von ein paar Nischen abgesehen) wirst du (O)RDBMS antreffen.

 

[konstantin]

Ansonsten kann ich nur PostgreSQL empfehlen, das ist *das* OpenSource DBMS der Zukunft. Für Embedded Devices evtl. noch Sleepycats Berkeley DB, aber die wurden grade von Oracle gekauft.

Hmm ... bisher habe ich immer MySQL genutz. Ist es also zu empfehlen, statt dessen PostgreSQL zu nehmen? Ich dachte immer, die beiden tun sich eigentlich nicht viel. Lohnt es sich umzusteigen?

 

[rbrinkmo]

Hmm ... bisher habe ich immer MySQL genutz. Ist es also zu empfehlen, statt dessen PostgreSQL zu nehmen?

Klare und allumfassende Antwort: Kommt drauf an.
Es hängt stark vom Einsatzgebiete ab. Wozu wird die Datenbank verwendet und welche Ansprüche hat man.

Ich dachte immer, die beiden tun sich eigentlich nicht viel. Lohnt es sich umzusteigen?

Beides sind OpenSource Datenbanken. In diesem Punkt tun sie sich nicht viel. Das war es aber auch schon.

Ich bin jetzt nicht auf dem Laufenden was MySQL 5 betrifft (da sollte ja einiges passieren) aber einige bis dato wichtige Unterschiede waren, dass PostgreSQL im Gegensatz zu MySQL z.B. Stored-procedures, Trigger, Foreign Key Constraints, write ahaed logging und Transaktionen beherscht.

Wenn ich also eine DB für's Web benötige welche sehr schnell ausgelesen werden kann und leicht handhabbar ist dann ist sicherlich MySQL die bessere Wahl.
Will ich aber die o.g. Funktionalitäten nutzen oder von einer kommerziellen DB wie DB2 oder Oracle zu einer Open Source Lösung wechseln so wäre sicherlich PostgreSQL die erste Wahl.

 

[Azazyel]

Hmm ... bisher habe ich immer MySQL genutz. Ist es also zu empfehlen, statt dessen PostgreSQL zu nehmen? Ich dachte immer, die beiden tun sich eigentlich nicht viel. Lohnt es sich umzusteigen?

Auch wenn MySQL mit Version 5 einige der Unzulänglichkeiten beseitigt hat, ist PostgreSQL immer noch wesentlich besser als MySQL, nicht nur was die Anzahl der Features, sondern auch deren Ausgereiftheit betrifft.

PostgreSQL hat außerdem noch einige andere Vorteile:

• Klartext-Backups der Datenbanken in Form von SQL-Befehlen, die man problemlos in andere DBMS füttern kann
• Bessere Performance bei komplexen Abfragen
• Bessere Unterstützung des SQL-Standards
• höhere Zuverlässigkeit (aus eigener Erfahrung)

Die Nachteile seien nicht verschwiegen:

• keine (eingebaute) Replikation
• kleinere Community als MySQL
• seltener bei Web-Hostern anzutreffen

Sofern dir die drei genannten Nachteile nichts ausmachen, gibt es eigentlich keinen Grund, auf MySQL zurückzugreifen.

 

[konstantin]

Die Nachteile seien nicht verschwiegen:

• keine (eingebaute) Replikation
• kleinere Community als MySQL
• seltener bei Web-Hostern anzutreffen

Sofern dir die drei genannten Nachteile nichts ausmachen, gibt es eigentlich keinen Grund, auf MySQL zurückzugreifen.

• keine (eingebaute) Replikation

OK.

• kleinere Community als MySQL

Na ja, schaun wir mal. ;-)

• seltener bei Web-Hostern anzutreffen

Das ist für mich kein Problem.


Danke schonmal, für die Antworten.

 

[minuseins]

Eines der Haupteinsatzgebiete für OODBMS ist CAD-Software, dort lässt sich das Datenmodell kaum in einer relationalen Datenbank abbilden, wofür sich die OODBMS-Hersteller auch fürstlich bezahlen lassen. Im Rest der Welt (von ein paar Nischen abgesehen) wirst du (O)RDBMS antreffen.

Was genau meinst du mit "CAD-Software" und Datenmodell?

Vielleicht denke auch nur zu gross. Fuer das reine Grundgeruest der parametrisch assoziativen Konstruktion mag eine reine OODBMS praktisch sein. Hier kann ich auch ohne Probleme mit Objekten arbeiten. Solange man mit diesem System keine Stuecklisten verwalten muss, Beziehungen zur Produktion, Kunde und Verkauf stellen muss. Auch die Abbildung einer hierrachischen Produktstruktur, duerfte mit OODBMS extrem Schwierig sein.

Die meisten PDM/EDM Systeme die ich so kenne, setzen auf deshalb auf ORDBMS auf.

Wie gesagt, vielleicht denke ich auch nur zu Gross und in bewaehrten Bahnen, das eine OODBMS in diesem Bereich fuer mich keinen Sinn gemacht haette.

Weitere freie OODBMS die mir einfallen wuerde:

http://www.eyedb.org/

da minus

 

[FierceOne]

Auch wenn MySQL mit Version 5 einige der Unzulänglichkeiten beseitigt hat, ist PostgreSQL immer noch wesentlich besser als MySQL, nicht nur was die Anzahl der Features, sondern auch deren Ausgereiftheit betrifft.

PostgreSQL hat außerdem noch einige andere Vorteile:

• Klartext-Backups der Datenbanken in Form von SQL-Befehlen, die man problemlos in andere DBMS füttern kann
• Bessere Performance bei komplexen Abfragen
• Bessere Unterstützung des SQL-Standards
• höhere Zuverlässigkeit (aus eigener Erfahrung)

Die Nachteile seien nicht verschwiegen:

• keine (eingebaute) Replikation
• kleinere Community als MySQL
• seltener bei Web-Hostern anzutreffen

Sofern dir die drei genannten Nachteile nichts ausmachen, gibt es eigentlich keinen Grund, auf MySQL zurückzugreifen.

Okay, aber ich glaube Klartext Backups kann MySQL auch! Ehrlich gesagt bin ich mir sogar sicher das das geht. Es sei denn ich habe Dich falsch verstanden und Du meinst was anderes....
Link:
http://dev.mysql.com/doc/refman/4.0/de/mysqldump.html

 

[kili]

Hat irgendwer in letzter Zeit mal goods (http://www.garret.ru/~knizhnik/goods.html) benutzt? Ich habe vor ein paar Jahren mal damit herumgespielt, hatte aber damals keinen wirklichen Anwendungsfall fuer so etwas.