Das deutsche Python-Forum

Aloah liebe Pythopathen,

Nachdem ich in den letzten Monaten hier viel mitgelesen habe und auch in ein paar Büchern geschmökert habe, ist es nun ander Zeit mit Python ernst zu machen.

Mein Vorhaben:

Eine vorhandene relationale Datenbank (MS SQL Server 2005) als Referenz hernehmen und diese mit den Objekten aus einer Objektdatenbank (ZODB/ZEO) "dekorieren". Ich habe das hier und nicht in der Rubrik ZOPE gepostet, weil ich ZODB/ZEO als standalone Objektdatenbank ohne den Overhead von Zope laufen lasse.

Und zwar sollen Daten in der Objektdatenbank gehalten und generiert werden und in die referenzierte SQL db exportiert werden. Jetzt mache ich mir Gedanken um die Verknüpfung und Synchronisation dieser beiden "Welten".
Ich stelle mir also eine Verwirklichung eines "FOREIGN KEY ON UPDATE, DELETE CASCADE" in der ZODB "REFERENCES" SQL vor um das einmal in Pseudo-SQL zu versuchen zu beschreiben.

Hoffentlich ist mein Ansinnen einigermaßen deutlich geworden. Da ich noch in der Konzeptionsphase bin, bräuchte ich dazu noch Input was es zu beachten gilt und ein paar Tipps wie man soetwas möglichst elegant in Angriff nimmt.

Edit: hat das "h" verschoben

Was spricht gegen ein ORM wie SQLAlchemy?

Btw: Es heisst Python -> Pythomanen

Es spricht eigentlich nichts gegen SQLAlchemy, aber auch nichts dafür. Mir gefällt der Ansatz von ZODB gut, integriert sich so nett in Python und fühlt sich einfach "richtig" an.

Ich möchte weg von dem relationalen Tabellengeraffel und objektorientiert arbeiten. Warum sollte ich dann die Objekte mit einem Mapper wieder in Tabellen ablegen, wenn ich eine so schicke Objektdatenbank/Server zur Verfügung habe? Ich habe SQL Alchemy nicht ausprobiert, bin aber für Tipps dankbar. Was wäre denn der Vorteil von SQLAlchemy im Vergleich zur ZODB und was der Nachteil?[/i]

Der Vorteil ist eben, dass du genau das bekommst, was du mit deinem ZODB Ansatz haben möchtest: Objekte. SQLAlchemy kümmert sich darum, dass du dich mit der relationalen Datenbank nicht rumschlagen musst, sondern an den Objekten arbeitest.

Aber so tief war ich noch nicht in der Materie. Vielleicht kann da noch jemand was dazu sagen?

sehbaer hat geschrieben:ZODB/ZEO als standalone Objektdatenbank

Hallo sehbaer!

Die ZODB ist sicher eine feine Sache. Man kann ziemlich gut mit richtigen "Objekten" arbeiten. Das Arbeiten mit einer Objektdatenbank hat aber auch ziemlich große Nachteile, die du auch in deine Entscheidungsfindung mit einbeziehen solltest.

Vorab: Ich habe mich auch mit der ZODB befasst und wollte damit größere Projekte realisieren. Und dabei sind mir auch einige Punkte klar geworden, die mich wieder davon abgebracht haben.

Es gibt keine Programme von Drittherstellern, die mit einer Ojektdatenbank klar kommen. Das heißt, dass du "alles" selber machen musst. Und damit meine ich wirklich ALLES.

Das fängt schon damit an, dass du die Objektdatenbank nicht einfach per ODBC an ein anderes Programm anbinden kannst. So kannst du die darin gespeicherten Daten NUR über dein eigenes Programm sichtbar machen. Du kannst also nicht einfach mal schnell nachsehen, welche z.B. Personen du in der Datenbank gespeichert hast, die aus München kommen. Das raus zu kriegen, bedeutet Handarbeit!

Dann gibt es kein verwendbares Programm, mit dem du druckbare Berichte mit Daten aus der ZODB erstellen kannst. Wenn du alle Adressdaten ausdrucken möchtest, dann musst du dich selber darum kümmern. Kein Programm unterstützt dich dabei.

Auch das schnelle Auffinden von Daten wird mit zunehmender Größe der ZODB immer schwieriger. Am Anfang kann man ohne Probleme alle Objekte durchlaufen, bis man das gewünschte Objekt gefunden hat. Aber wenn die ZODB größer wird, dann muss man unbedingt mit Indizes (Katalogen) arbeiten. Und die muss man selber erstellen. Die Kataloge werden nicht automatisch verwendet. Man muss beim Suchen nach Daten die Kataloge selbst abfragen. Es kann sein, dass das die letzten Jahre einfacher geworden ist -- mir fehlt die letzte Zeit der Überblick über die Entwicklung der ZODB.

------------------

Relationale Datenbanksysteme haben zwar den Nachteil, dass man damit nicht so einfach Objekte nachbilden kann, mit denen man direkt programmieren kann, dafür erfreuen sie sich allgemeiner Beliebtheit. Es gibt viele Programme von Drittherstellern, die einem sehr viel Arbeit abnehmen können und sie können teilweise ohne Probleme mit Terrabyte großen Datenmengen umgehen, ohne dass sie in die Knie gezwungen werden. Es gibt sie in Klein (z.B. SQLite) und in Groß (z.B. PostgreSQL).

Ich persönlich, arbeite direkt mit den Datenbanken. Ich habe also keine Mapper, die mir die Daten in programmierbare Objekte umwandeln. Aber man kann beides haben. Man kann die Vorteile der relationalen Datenbanksysteme (Geschwindigkeit, SQL, 3rd-Party Programme, Schnittstellen, usw.) mit programmierbaren Objekten verbinden. Das funktioniert mit Schnittstellen wie z.B. SQLAlchemy. Der Overhead ist klein und lässt dich intuitiv mit Datenobjekten arbeiten. Nur würde ich nicht direkt "SQLAlchemy" verwenden, sondern "Elixir", welches auf "SQLAlchemy" aufbaut. Es macht weniger Arbeit, die Datenstruktur damit aufzubauen und der Zugriff auf die Daten kommt mir intuitiver vor. Und trotzdem hast du vollen Zugriff auf die Möglichkeiten von SQLAlchemy -- wenn du sie brauchst.

Mein Fazit: ZODB ist ein schönes Projekt -- aber relationale Datenbanken haben sich durchgesetzt und erfreuen sich großer Unterstützung. Somit lassen sich, meiner Meinung nach, kleine und große Projekte schneller, einfacher und zukunftssicherer mit relationalen Datenbanken erstellen.
Wenn man nicht direkt mit relationalen Datenbanken arbeiten möchte -- wenn man stattdessen lieber mit programmierbaren Objekten arbeiten möchte, dann sollte man zu einem ORM wie z.B. SQLAlchemy greifen. Und wer es noch einfacher haben möchte, der sollte gleich zu Elixir greifen, denn damit wird der Datenzugriff einfacher, ohne dass man auf die Mächtigkeit von SQLAlchemy verzichten muss.

mfg
Gerold

Hallo Gerold,

Danke für Deine ausführliche Antwort. Da ich auf die SQL Datenbank aus performance/security Gründen in der Regel über selbst erstellte SQL-Funktionen zugreife und mit selbsterstellten SQL-Prozeduren bearbeite, wäre mir die Notwendigkeit Alles für die Ein- und Ausgabe selbst zu implementieren nicht fremd und damit auch nicht soo der Nachteil und schon gar kein "Showstopper". Das Berichtswesen wird aus der SQL Datenbank weiterhin geführt. Dort gibt es qasi als API einige Tabellen /Views aus denen sich verschiedene andere Anwendungen/Prozesse ihre Daten abholen. Das ist nicht schön so aber historisch bedingt und wohl nicht so bald abzustellen. Meine Aufgabe ist es diese Tabellen mit den entsprechend aufbereitetem Content zu füttern. Mein Ziel ist es jetzt, daß die Objekte diesen Content quasi selbst erzeugen. Ich möchte also beispielsweise dahin: Diese Artikel-Objekte mit ihren Methoden möchte ich in einer DB ablegen. Wenn das dann so funktioniert, wie ich mir vorstelle, dann kann ich die historischen "API" Tabellen elegant füttern bzw. diese Funktionalität ganz elegant als API zur Verfügung stellen, damit die nachgelagerten Prozesse (Webdesign, Katalogdesign, Fakturierung etc.) auf diese Methoden direkt zugreifen können und ggf. Gefallen daran finden.

Prinzipiell hatte ich auch schon einmal angefangen in der SQL Datenbank quasi objektrelational zu arbeiten, erscheint mir aber ein wenig "aufgesetzt" und fühlt sich nicht gut an. Vielleicht daher auch meine Ressentiments zu den ORMs. Bei der ZODB nehme ich das Objekt und packe es in die ZODB und fertig. Da brauche ich mir nicht Tabellenkram und Datentypendeklaration anzutun. Zur Synchonisation mit den Stammdaten habe ich auch schon Ideen, wärde aber immer noch fü Tipps diesbzüglich empfänglich.

Elixir habe ich mir gerade ganz ganz kurz angeschaut und das Codebeispiel von der Elixir site lässt mich ein wenig erschauern:
Wenn ich jetzt in Python Datentypen deklarieren muß usw. dann kann ich ja gleich in SQL weiterfummeln. Ich kann da jetzt für mich keinen Vorteil entdecken, außer daß ich das nicht explizit in SQL hinschreiben muß. Soetwas würde mir persönlich aber in SQL leichter fallen. Im Elixir Tutorial enthalten die Klassen respektive Objekte nur Attribute und keine Methoden. Kann man keine Methoden in den "Elixir-Objekten" ablegen? Daß wäre ein Showstopper für mich. Sind die Objekte für SQLAlchemy/Elixir eigentlich irgendwelchen Restriktionen unterworfen?

Alles in Allem scheinen mir diese ORM im Wesentlichen für Entwickler mit SQL Abneigung gemacht zu sein. Oder wenn man variable DB als Backend verwenden möchte. Einen prinzipiellen Vorteil müsstet ihr mir noch näher bringen. Performace evtl.? Gibt es da objektive Tests ORM vs. ODB?

Zudem kann ZODB als Storage auch in eine relationale Datenbank (PostgreSQL, Oracle, MySQL) pickeln (RelStorage). Das habe ich aber noch nicht ausprobiert, vermute aber, recht kryptische Inhalte im Storage, die man ohne ZODB nicht so ohne weiteres verwenden kann, wäre aber nur von akademischen Interesse.