ORM = Abstraktionsschicht?

[droptix]

Ich möchte eine Python-App schreiben, die mehrere DB-Typen bedienen kann. Hierfür bedient man sich ja gängigerweise einer Abstraktionsschicht. Für PHP verwende ich sehr gern ADOdb, weil haufenweise DBs unterstützt werden.

Für Python ist ADOdb nahezu unbrauchbar. Es werden nur extrem wenige Typen unterstützt und dann noch nicht mal mit 100%iger Unterstützung (einige Befehle/Methoden gehen nicht).

Frage: Durch Leonidas bin ich auf die ORM (Object Relational Manager/Mapping) Systeme SQLObject und SQLAlchemy aufmerksam geworden. Ich werde allerdings nicht ganz schlau daraus, was die genau machen.

Gut, sie stellen die Inhalte wie Tabellen und Datensätze als Objekte dar. Damit lässt sich nett arbeiten. Wie aber steht's um eine Abstraktionsschicht?

Ich suche was, womit ich Datenbankabfragen vereinheitlichen kann (s. ADOdb). Also ein SELECT mit LIMIT sieht bei verschiedenen Datenbank-Typen auch unterschiedlich aus. Ich will aber nur eine einheitliche Abfrage starten, die mir die Abstraktionsschicht dann in die jeweilge native SQL-Syntax übersetzt.

Sind also die beiden genannten ORMs auch gleichzeitig Abstraction Layers? Und: Was kann man grundsätzlich noch empfehlen?

[Leonidas]

Sind also die beiden genannten ORMs auch gleichzeitig Abstraction Layers? Und: Was kann man grundsätzlich noch empfehlen?

Ja natürlich, sogar mehr als das: sie abstrahieren die SQL-Syntax der Datenbanken so weit, das du keinen SQL-Code mehr brauchst, sondern direkt mit Python-Objekten arbeitest. Das was du mit den Objekten anstellst wird von den ORMs von selbst in datenbankabhängigen SQL-Code verwandelt und ausgeführt.

Aber so eine ähnliche Diskussion hatten wir schon einmal.

Ich bin immer noch auf dem selben Standpunkt: wenn SQL dann habe ich lieber Kontrolle über das SQL, was wirklich ausgeführt wird. Wenn ich SQL nicht direkt brauche (und SQL direkt brauch ich eigentlich selten) dann verzichte ich lieber komplett auf SQL und nutze lieber ein ORM oder, noch besser eine OODB.

[droptix]

Eben, durch diese Diskussion hab ich auch nochmal nachgedacht und hab tiefer reingeschaut.

Da meine Python-App aber möglichst viele DB-Modelle unterstützen soll, kann ich nicht für jeden Fall die native SQL-Syntax hinschreiben.

Daher möchte ich eine Abstraktionsschicht verwenden. Was ist daran so "schlimm". Diese ORMs sind doch direkt dafür gemacht.

[BlackJack]

So eine richtig gute SQL Abstraktionsschicht ist IMHO gar nicht möglich bei den vielen SQL-Dialekten. Nahezu *jede* Datenbank weicht vom Standard ab. Die DB-API 2 und ein wenig Selbstdisziplin haben mir bisher immer ausgereicht.

ORMs machen die Benutzung einfacher, aber man hat halt nicht mehr die Kontrolle die man bei handgeschriebenem SQL hat. Kommt auf den Einsatzzweck an, ob das okay ist, oder nicht.

[Leonidas]

Was ist daran so "schlimm". Diese ORMs sind doch direkt dafür gemacht.

Schlimm: nichts. Nur gibt es nichts was genau deine Anforderungen erfüllt, was auch an der recht geringen Nachfrage (siehe BlackJacks Post) hängt. Es gibt daher mehr Interesse an ORMs da du damit eine noch höhere Akstraktion bekommst. So musst du nicht mehr zwei Programmiersprachen können, sondern Programmierst in Python. Immer. Dafür gibst du eben etwas Kontrolle aus der Hand. Wie BlackJack meinte: das hängt davon ab, wie viel Kontrolle du haben willst/musst.

[droptix]

Na ich will natürlich möglichst volle Kontrolle

Bei mir geht's um ein paar SELECTs (manchmal auch etwas komplexer), INSERTs und UPDATEs. Wenn ich mich darauf verlassen, dass ORM das in die korrekte Syntax übersetzt, behalte ich doch die volle Kontrolle.

Nur eben nicht die volle Power, weil einige DBs was können, was andere nicht können. Eine gute Abstraktionsschict sollte sowas dann aber emulieren und ausgleichen können. ADOdb macht sowas.

[jens]

Also ich überlege auch, ob ich nicht evtl. SQLAlchemy bei PyLucid nutzten sollte. Ist recht klein...
...oder doch nicht, hab gerade mal nachgesehen:
Die aktuelle 0.2.7 ist ca. 625KB zum download!
PyLucid ist in der neuen Version gerade mal ca. 410KB groß...

Das steht in keinem Verhältnis Was ist denn bei SQLAlchemy alles dabei???

Naja, wie dem auch sei...

Ich weiß nur nicht wie groß der Overhead bei SQLAlchemy wäre... Eben mal testen wäre mich relativ viel Aufwand verbunden... Ich meine ein ORM ist auf der einen Seite bequemer, auf der anderen Seite frist das Preformance...
Da PyLucid auch mit CGI funktionieren soll, ist das für mich schon ein wichtiger Punkt...

Ich denke ich würde, wenn, dann auch nicht alle Features von SQLAlchemy nutzten, sondern ehr nur die Punkte, die auf der Hauptseite unter "Scales Down" aufgelistet sind:

Extremely easy to use for all the basic tasks, such as:

* Constructing SQL from Python expressions
* Pooling database connections
* Loading objects from the database and saving changes back

Ich meine SQLObject hat ein riesigen Overhead, hätte blackbird mal geschrieben, deswegen nutzt pocoo SQLAlchemy.

Irgendwer Erfahrung gesammelt?

[BlackJack]

Na ich will natürlich möglichst volle Kontrolle

Bei mir geht's um ein paar SELECTs (manchmal auch etwas komplexer), INSERTs und UPDATEs. Wenn ich mich darauf verlassen, dass ORM das in die korrekte Syntax übersetzt, behalte ich doch die volle Kontrolle.

ORMs bilden Attribute von Objekten und Objektbeziehungen auf das relationale Modell ab. Du entwirfst also die Objekte und nicht mehr die Relationen. Das heisst Du brauchst Dir um Normalformen keine Gedanken mehr zu machen, bzw. kannst diese auch nicht absichtlich verletzen falls es nützlich erscheint. Und der ganze andere DB Kram wie Views, Triggers, stored procedures usw. ist auch aus dem Blick.

Und da kommt es eben auf den Einsatzzweck an, ob das gut oder schlecht ist.

[BlackJack]

Also ich überlege auch, ob ich nicht evtl. SQLAlchemy bei PyLucid nutzten sollte. Ist recht klein...
...oder doch nicht, hab gerade mal nachgesehen:
Die aktuelle 0.2.7 ist ca. 625KB zum download!
PyLucid ist in der neuen Version gerade mal ca. 410KB groß...

Das steht in keinem Verhältnis Was ist denn bei SQLAlchemy alles dabei???

Dokumentation.