Das deutsche Python-Forum

Das gehört weder richtig zur Datenbankprogrammierung noch zu Qt/KDE. Und die Frage in beiden Foren zu stellen wäre allemal verkehrt. Also hier.

Ich bin dabei, eine Datenbankanwendung von WPF / C# auf Python umzustellen, weil mir C# mit jeder neuen Version schlimmer auf die Nerven geht. Außerdem kenne ich Python besser und schon sehr viel länger.

Potentiell wichtige Eigenschaften von Datenbank und Programm:

- Einziger Benutzer und "Datenbankadministrator" bin ich selbst. Das heißt, ich will keine falschen Daten in die Datenbank hineinkriegen, ohne es zu merken, Abstürze o.ä. sind aber kein Drama und an der Oberfläche kann ich nach meinen Wünschen drehen. Im Grunde bleibt das Programm eine Testversion, so lange es lebt. Und für so einen Umgang mit Programmen eignet sich C# m.E. nicht und ist dafür auch nicht gedacht.

- Datenbanksystem ist PostgreSQL, allerdings wäre eine Umstellung auf SQLite möglicherweise eine ganz gute Idee. Die Datenbank ist klein und dürfte dauerhaft klein bleiben.

- Als GUI ist PyQt vorgesehen, damit kenne ich mich vergleichsweise noch am besten aus. Die SQL-Komponenten von Qt will ich aber nicht benutzen: für PostgreSQL unter Windows scheinen sie im Pyqt6-Paket gar nicht drin zu sein, und im übrigen finde ich sie auch nicht wirklich praktisch.

- Ich kenne mich mit SQL durchaus ganz gut aus, so weit es weder um Parallelbetrieb noch um ernsthaft große Datenmengen geht. Aber bei der Aktualisierung von psycopg2 auf psycopg 3 musste ich in einem anderen Programm doch ziemlich viel an verstreuten Stellen ändern. Und eine mögliche Umstellung auf SQLite ist ganz sicher ein Grund, SQLAlchemy zu benutzen - obwohl (oder weil) ich damit noch kaum Übung habe.

- Die Frage "Core oder ORM?" stellt sich deshalb, weil ich zwar QtSql vermeiden, aber die Model-View-Komponenten von PyQt sehr wohl benutzen will (oder sogar muss?). Weil die ursprüngliche Anwendung das Entity Framework benutzt, habe ich zuerst etwas blindlings ORM-Klassen definiert und habe sie auch erfolgreich mit einem PyQt-GUI verbunden - aber es kommt mir nicht wirklich vernünftig vor. Die PyQt-Model-Klassen wollen doch die Daten in einer Tabellenform bekommen, wie sie eher von den Core-Methoden von SQLAlchemy geliefert werden - ORM-Abfrageergebnisse müssen erst in ihre Felder zerlegt werden. Allerdings kann man natürlich verknüpfte Daten bequemer mitliefern.

Das war jetzt vielleicht etwas länglich, aber ich wollte Hintergrund zu der Frage liefern.

Das würde ich getrennt von Qt betrachten, wenn dortige Tools nicht in Frage kommen.

Wenn deine Anwendung nur lokal läuft, dann kann SQLite eine gute Wahl sein, selbst falls die Datenmenge größer wird. Unangenehm kann es werden, wenn es später erforderlich sein sollte, die Datenbank zu wechseln. Das sollte man im Vorfeld beachten.

Wenn du gut SQL kannst, dann kannst du SQL auch direkt verwenden. Sobald du aber viel SQL schreiben musst, wirst du wahrscheinlich in eine Vielzahl von redundanten Code laufen. Als Lösung bietet sich an, daraus ein eigenes ORM zu entwickeln, was gar nicht so aufwendig ist, solange es nicht generisch sein soll. Letzteres hingegen ist *sehr* viel Arbeit und dann empfiehlt es sich, ein fertiges ORM zu nutzen, auch wenn dies Zeit zur Einarbeitung erfordert. SQLAlchemy hast du ja schon genannt.

kbr hat geschrieben: Sonntag 2. März 2025, 15:08 Das würde ich getrennt von Qt betrachten, wenn dortige Tools nicht in Frage kommen.

Nicht unbedingt. SQLAlchemy hat ja nun diese beiden Möglichkeiten: ORM oder Core. Und mir geht es darum, diejenige zu wählen, die mit Qt besser zusammenarbeitet. Auf den ersten Blick sind das die Core-Methoden, denn die liefern Abfrageergebnisse in einer Form, die sich sehr leicht in Qt-Models importieren lässt. Auf den zweiten Blick bekommt man bei ORM-Klassen so schön einfach die verknüpften Sätze aus anderen Tabellen mitgeliefert. Andererseits muss man die Ergebnisse für ein Qt-Model umformen.

Wenn deine Anwendung nur lokal läuft, dann kann SQLite eine gute Wahl sein, selbst falls die Datenmenge größer wird. Unangenehm kann es werden, wenn es später erforderlich sein sollte, die Datenbank zu wechseln. Das sollte man im Vorfeld beachten.

Das ist ein Hauptgrund, SQLAlchemy in Erwägung zu ziehen (es geht ggf. um den Umstieg nicht von, sondern auf SQLite, aber das ist ja egal). Der andere Hauptgrund ist schlicht der, dass ich so wenig Erfahrung damit habe und das ist kein Zustand.