Ich stimme mit gerold durchaus darin überein, dass es Sachen gibt, die am Besten in Händen des DBMS passieren. Das sind teilweise aber auch Bereiche, an die man mit SQL nur begrenzt heran kommt oder ohnehin nicht aus der Applikation selbst einrichtet und verwaltet.
Ebenfalls muss ich anerkennen, dass die DB-API gerade gegenüber dem, was das gemeine PHP-Opfer so kennt, eine feine Sache ist.
Dennoch fehlt SQL - logischerweise - eine Integration in die eine oder andere Programmiersprache, und da punktet dann ein ORM. Insgesamt flexibel für den anspruchsvollen Einsatz ist in meinen Augen wiederum nur
ein ORM.
Wenn man nicht sicher ist, welches DBMS man einsetzt bzw. sich die Option eines Wechsels offen halten möchte, ist ein gutes ORM viel Wert. Nur so war es mir möglich, die ersten meiner Applikationen endlich von MySQL auf eine *richtige* Datenbank (jaja, jetzt kann ich das Bashing verstehen
) umzuziehen.
Dennoch habe ich einige kleine Projekte, die ich inbesondere auch mal veröffentlichen möchte, bei denen ein ORM dem Anwender die Wahl lässt, ob er es als alter DBA-Hase mit PostgreSQL oder anspruchslos mit SQLite benutzen möchte.
Nachtrag: Nach dem Lesen des Logs mit __doc__ erlangt die Unterscheidung von SQLAlchemys verschiedenen Ebenen wieder Bedeutung, *ist* es doch kein ORM, sondern bietet ein ORM als Feature, erlaubt aber auch sehr Schema-nahe Modellierung und Abfragen.