Das deutsche Python-Forum

Hallo Forum,

mangels fehlender Erfahrung meinerseits, und der unüberschaubar großen Auswahl an Bibliotheken und Tools, wollte ich an dieser Stelle vorsichtig wie ihr mit der Datenbankanbindung umgeht.
Meine Erfahrungen kommen aus der Java Ecke mit Hiberante, und das ist auch schon eine Weile her.

Angenommen ihr entwickelt an einer Anwendung die allgemein interessant sein könnte, also nicht nur in einer Umgebung (daheim, Firma) die ihr weitestgehend unter Kontrolle habt.

Um dem Anwender eine möglichst gute Möglichkeit zu geben eine Anwendung in seine bisherige Systemlandschaft zu integrieren könnte man eine entsprechende Middleware einsetzen (also so etwas wie SQL Alchemy). Der Anwender könnte mit relativ wenig Konfiguration dafür sorgen, dass die Anwendung auf dem bestehenden DBMS eine Datenbank anlegt und entsprechend verwendet.

Das sehe ich als Vorteil gegenüber der direkten Benutzung einer bestimmten Datenbank. Obwohl so eine Middleware unter Umständen Features der Datenbank verdeckt.

Als großen Nachteil sehe ich, dass irgendwann im Zuge eines Updates der Anwendung auch Updates am Schema der Datenbank vorgenommen werden müssen. Würde ich direkt und "hard" auf einer Datenbank entwickeln würde ich für das Update entsprechende "ALTER"-Statements nacheinander ablaufen lassen und die Datenbank wäre bereit für die neue Version.
Bei einer verwendeten Middleware fühlt man sich dann immer so... hilflos

Mag mir jemand beim Abwägen helfen?

Gruß
Sparrow

Der Autor von SQLAlchemy hat für Schema Migrationen vor kurzem Alembic veröffentlicht. Wenn man Django nutzt gibt es mit South ebenfalls eine Lösung für dieses Problem.

Letztendlich kannst du aber immernoch eine Reihe von ALTER statements ausführen, bei der Datenbank ist man ohnehin häufig soweit eingeschränkt dass die Entscheidungsmöglichkeiten, die einem die verwendeten Abstraktionen bieten, irrelevant werden.

Hallo,

anfangs habe ich auch auf nacktes SQL gesetzt, heute sag ich (weiß ich ): SQLAlchemy ist besser. Selbst wenn du nicht das ORM benutzt, hat die SQL Expression Language Vorteile gegenüber SQL direkt. Zumal du ja im Zweifelsfall auch aus SQLAlchemy heraus "hartes" SQL direkt ausführen kannst.

Bzgl. der anderen Frage: Wenn du eine Applikation weiter entwickelst und dabei u.U. mehr Spalten oder Tabellen in der Datenbank brauchst, dann muss du dein Mapping ja sowie so anpassen. Das geht zumindest bei SQLAlchemy aus beiden Richtungen. SQLAlchemy kann basierend auf einer bestehenden Datenbank automatisch ein Mapping erstellen. Das macht aber eigentlich primär nur Sinn, wenn du eine Legacy Datenbank hast, wo alles fix ist. Oder die erweiterst das Modell in SQLAlchemy und lässt daraus die Tabellen anlegen.

Wenn du eine reale, produktive Applikation hast, dann kommst du um eine Mischform bei der Migration wahrscheinlich nicht umhin. Wobei das "alter" ja einmalig wäre, nämlich nur, wenn du von Version x.y auf Version x.z upgradest.

Gruß, noisefloor

@noisefloor: Ich bin mir ja durchaus über die Vorteile bewusst die eine Middleware bzw. ein ORM-Mapper mit sich bringen, keine Frage. Ich würde auch ungern nacktes SQL verwenden wollen. Höchstens für Auswertungen.

@DasIch: Alembic sieht danach aus als wenn einem genau da helfen soll. Das schaue ich mir näher an, danke!