ORM = Abstraktionsschicht?

Installation und Anwendung von Datenbankschnittstellen wie SQLite, PostgreSQL, MySQL, der DB-API 2.0 und sonstigen Datenbanksystemen.
Antworten
droptix
User
Beiträge: 521
Registriert: Donnerstag 13. Oktober 2005, 21:27

Donnerstag 31. August 2006, 11:33

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
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Donnerstag 31. August 2006, 11:58

droptix hat geschrieben: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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
droptix
User
Beiträge: 521
Registriert: Donnerstag 13. Oktober 2005, 21:27

Donnerstag 31. August 2006, 12:15

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

Donnerstag 31. August 2006, 13:13

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
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Donnerstag 31. August 2006, 13:30

droptix hat geschrieben: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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
droptix
User
Beiträge: 521
Registriert: Donnerstag 13. Oktober 2005, 21:27

Donnerstag 31. August 2006, 13:58

Na ich will natürlich möglichst volle Kontrolle :D

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.
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Donnerstag 31. August 2006, 14:02

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?

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
BlackJack

Donnerstag 31. August 2006, 16:10

droptix hat geschrieben:Na ich will natürlich möglichst volle Kontrolle :D

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

Donnerstag 31. August 2006, 16:11

jens hat geschrieben: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.
Antworten