Seite 1 von 1

Suche: Objektorientierte Datenbank...

Verfasst: Dienstag 14. Dezember 2004, 18:31
von jens
Hab von dem Prinzip einer Objektorientierten Datenbank gehört...
Wer weiß was darüber, lohnt sich das gerade für Python? Besser als MySQL?
Gibt es eine OpenSource für Linux/Windows ?

http://de.wikipedia.org/wiki/Objektorie ... _Datenbank

EDIT: Aha, es gibt u.a. die Zope Object Database: http://zope.org/Wikis/ZODB/FrontPage Sogar Binaries für Python unter Windows gibt's... taugt das was?
Eine deutschsprachige Einführung: http://www.thomas-guettler.de/vortraege ... hrung.html

Ich denke das coole an ZODB ist es, das es ideal für Python ist, weil es in Python für Python geschrieben ist...

EDIT2: So hab mir mal Beispiele angeschaut... Ist schon interressant! Aber leider habe ich bisher nur kleine Beispiele gefunden, die eine DB eröffnen, einen "Datensatz" speichern und wieder auslesen... Nicht jedoch wo eine existierende Datenbank weiter vollgeschrieben wird...

Verfasst: Dienstag 14. Dezember 2004, 21:21
von EdiRitter
Hallo,

man unterscheidet zwischen objektorientierte DB - Systeme (OODBMS) und objektrelationale DB - Systeme (ORDBMS). Wir haben uns mit den objektorientierten Erweiterungen von Oracle auseinandergesetzt (ORDBMS). Sieht ungefähr so aus:

Code: Alles auswählen

create type name_t as object (nachname char(25), vorname char(25));
create type adresse_t as object (stadt char(25), strasse char(25), hausnr int);
create type person_t as object (name name_t, adresse adresse_t, telefon_nr INT, geb_datum DATE);
create table person of person_t;

select p.name.vorname
  from person p
  where telefon_nr = 33333;
So gesehen ist es interessant zu sehen welche Möglichkeiten es mittlerweile schon gibt. Mir fehlt aber ehrlich gesagt der praktische Nutzen von Objektdatenbanken.

Ich habe die ZODB(ich nehme an OODBMS) kurz überflogen. Muss ehrlich gestehen, es hat mir gefallen, was ich dort gelesen habe. Python = Objektorientiert, ZODB = Objektorientiert.

Ich programmiere erst seit Kurzem mit Python, deshalb kann ich dir leider nicht mehr sagen. Ob man jetzt seine Objekte serialisiert oder besser ZODB hernimmt :?:

MfG

Verfasst: Dienstag 14. Dezember 2004, 21:50
von Leonidas
Es gibt auch sowas wie ORM - Object Rationals Mapping, wo du Objekte so erstellst, dass sie in ein RDBMS passen und von dort auch wieder geladen werden können.

ZODB: ist ganz lustig, aber ich finde es total den Overkill, Python + C Extensions... aber vermutlich als Datenbank besser/mächtiger als gadfly. Kann auch Persistence direkt und BTrees.

Verfasst: Mittwoch 15. Dezember 2004, 07:11
von jens
Was meinst du mit Overkill? Ich meine ZODB ist winzig klein gegenüber MySQL... Dennoch scheint es eine Ausgewachsene Datenbank zu sein...

Hat jemand schon mehr erfahrungen damit gesammelt???

Verfasst: Mittwoch 15. Dezember 2004, 07:31
von jens
EdiRitter hat geschrieben:So gesehen ist es interessant zu sehen welche Möglichkeiten es mittlerweile schon gibt. Mir fehlt aber ehrlich gesagt der praktische Nutzen von Objektdatenbanken.
Naja, ich denke der größte vorteil ist es, das man nicht die Daten "umformen" muß um sie in Tabellen aufzuteilen... Ich meine die Daten behalten ihren natürlichen OO zusammenhang...

Hier hab ich einen ganz guten Text gefunden:
http://zope.org/Members/adytumsolutions ... ZODB_PartI


Wobei jetzt wo ich mir die Sachen ein klein wenig näher angeschaut hab, kommen mir ein paar Zweifel... In den Beispielen, die ich bisher gesehen hab, hatten immer alle Objekte die geleichen Eigenschaften... Doch was ist, wenn von 10000 Objekten nur 10 eine bestimmte Eigenschaft besitzt? Erhalten dann alle Objekte diese Eigenschaft und bei 9990 ist diese leer??? - Vielleicht hab ich's auch noch nicht ganz verstanden :?:

Verfasst: Mittwoch 15. Dezember 2004, 14:39
von Leonidas
jens hat geschrieben:Was meinst du mit Overkill? Ich meine ZODB ist winzig klein gegenüber MySQL... Dennoch scheint es eine Ausgewachsene Datenbank zu sein...
Du versuchst eine objektorientierte Datenbank die man meist embedded mit einem RDBMS zu vergleichen, dass (seine Art von) SQL versteht.

Du solltest für den MySQL Vergleich besser SQLite bzw Gadfly hinzuziehen. Was mir an ZODB nicht wirklich gefällt ist, dass es imo kompliziert ist (so hatte ich meine Probleme mit der Persistence eines VFS mit ZODB Backend). Klar, sie ist sicher cool, deswegen habe ich sie mir angesehen, aber ich vermute ich bein bei ORM oä besser aufgehoben, da das auch noch schneller ist und auch über andere Programmiersprachen zugreifbar.

Verfasst: Mittwoch 15. Dezember 2004, 14:53
von jens
Ja kompliziert ist es schon... Das liegt aber vielleicht nur daran, das ich es noch nicht ganz verstehe ;)
ZODB und alle anderen DB außer SQL haben allerdings gemein, das sie bei WebSpace Providern zu 95% nicht dabei sind :( Das ist schon ein dicker Pluspunkt für SQL... Somit ist die Frage, ob OODB so viel besser ist, um den zusätzlich Aufwand zu rechtfertigen...

Ein SQL Aufsatz halte ich dagegen für weniger Sinnvoll... OK ich kenne auch keinen, aber SQL von Python aus zu benutzen ist doch eh ziemlich leicht...

Verfasst: Mittwoch 15. Dezember 2004, 15:13
von Leonidas
Du kannst immerhin noch ORM nutzen und es in MySQL speichern, das ist zwar weniger elegant aber sollte auch gehen.

Ich bin davon abgegenagen, meine Seiten bei "Profis" zu hosten, ich nutze irnzischen nur noch private Server (oder eigene), wo auch lieber auf Sonderwünschen eingegangen wird :)

Verfasst: Mittwoch 15. Dezember 2004, 15:24
von jens
Naja, das ist allerdings auch dementsprechend teuer! Ich nehme z.Z. HostEurope... Schon ab 3€ im Monat hat man u.a. Python und MySQL...

Nur, ein eigener ergänzenden Server mit DSL angebunden, würde ich auch realisieren, wenn sich der Aufwand lohnt...

Kannst du noch ein paar Info's zu ORM schreiben? Bzw. ein paar Links?

Verfasst: Mittwoch 15. Dezember 2004, 16:00
von Leonidas
jens hat geschrieben:Naja, das ist allerdings auch dementsprechend teuer! Ich nehme z.Z. HostEurope... Schon ab 3€ im Monat hat man u.a. Python und MySQL...
Ich habe für 0 € zwar keine hübsche Domain, dafür aber Python, Spyce, CGI, MySQL, PostgreSQL, Cheetah.. es lohnt sich öfers mal einfach einige Leute zu fragen.
jens hat geschrieben:Nur, ein eigener ergänzenden Server mit DSL angebunden, würde ich auch realisieren, wenn sich der Aufwand lohnt...
Das geht nicht so einfach, denn da muss das Programm selbst auch das lokal installierte ZODB Modul zugreifen... ist eigentlich mit allen DBMS so..
jens hat geschrieben:Kannst du noch ein paar Info's zu ORM schreiben? Bzw. ein paar Links?
Kein Thema! ORM heißt "object relational mapper" und bezeichnet eine Möglichkeit Objekte so zu entwerfen, dass sie ohne weiteres direkt in ein RDBMS gespeichert und geladen werden können. Links habe ich auch für dich, ich habe mal SQLObject benutzt (das hat Wrapper für MySQL, Postgre, SQLite und noch einige nonfrees), aber beim Suchen habe ich auch Python Database Objects gefunden. Es gibt davon eine ganze Menge, am besten du guckst dir mal diese Wiki Seite an und testest selbst. Ich habe das Gefühl das SQLObject zu den besseren gehört, unter anderem auch deswegen weil es von Ian Bicking ist, der auch an Webware und dessen ORM MiddleKit gearbeitet hat :)

Verfasst: Samstag 25. Dezember 2004, 11:37
von jens
So, ich hab mir ZODB noch etws angeschaut... Aber ich denke ich werde doch keine OODB nutzen...
Mir gefällt es nicht ganz, das es keine richtige Trennung zwischen Daten und Programm besteht... Das ist dann dumm, wenn man eine Methode hinzufügen will... Also quasi das Programm erweitern... Das ist nicht so einfach. Wohingegen man bei SQL einfach eine neue Spalte oder eine Tabelle hinzufügen kann...
Mir erscheint es also so, das man mit einer OODB-Lösung das Programm schon 100% fertig haben muß, was die Datenorganisation betrifft...

Außerdem hat man mit einer SQL Lösung mehr transparenz, man kann sich einfach mit PHPMyAdmin o.ä. die Tabellen/Daten anschauen... Das ist bei ZODB etwas schwieriger...

Verfasst: Sonntag 26. Dezember 2004, 00:15
von Beyond
In Zope gibt's dazu __setstate__ / __getstate_damit kannst Du Deine Daten soz. updaten. Es ist kein Problem Dinge hinzuzufügen oder sogar Objekte so abzuändern, daß neue Daten gespeichert werden.

cu beyond