PySide-Programm: SQLite besser mit QtSql oder sqlite3 ?

Installation und Anwendung von Datenbankschnittstellen wie SQLite, PostgreSQL, MariaDB/MySQL, der DB-API 2.0 und sonstigen Datenbanksystemen.
Antworten
mephisto-online
User
Beiträge: 167
Registriert: Sonntag 29. September 2013, 17:05

In meinem PySide-Projekt habe ich als Datenbank-Noob eine Ortssuche in einer SQLite-DB mit geonames.org-Daten (zwei Tabellen: cities und timezones) mit dem QtSql-Modul "zusammengebastelt" (QSqlQueryModel, QTableView) und es funktioniert hervorragend ! :P

Vorher hatte ich meine ersten Versuche mit den indizierten geonames-Daten (2,8 GB) mit dem sqlite3-Modul gemacht und habe festgestellt, dass die SELECT-Abfrage (select x, y, z from cities where name like abc) schneller ging als jetzt mit dem Qt-Modul (gefühlt etwa 1-2s mit sqlite3 und 5-6s mit Qt) . :?

Da ich hier gelernt habe, dass es Sinn macht, Programm- und DB-Logik voneinander zu trennen, denke ich nun darüber nach, ob ich nicht die ganze Datenbank-Seite meines Programms mit sqlite3 machen sollte. Die in einem cursor selektierten Daten kann man ja auch problemlos in einem QTableWidget anzeigen und auswählen. Auch meine geplanten Datenbank-Operationen werden, graphisch gesehen, nicht über solche Auswahl-Widgets hinausgehen.

An welcher Stelle könnte ich denn mit sqlite3 anstatt von QtSql in Verbindung mit Qt Schwierigkeiten bekommen ?
Wie sieht es mit den Datentypen aus ?
Wenn ich das Programm irgendwann einmal mit einer PostgreSQL- oder MySQL-DB benutzen möchte, wäre es dann nicht sinnvoll, doch eher mit QtSql oder gar SQL-Alchemy zu arbeiten ?

Da ich datenbankmässig mit meinem Programm noch ganz am Anfang stehe, möchte ich gerne jetzt eine Entscheidung treffen und würde ich mich über ein paar Aspekte freuen, die ich vielleicht noch gar nicht bedacht habe.
mephisto-online
User
Beiträge: 167
Registriert: Sonntag 29. September 2013, 17:05

Habe die Orts-Suche jetzt auf sqlite3 umgeschrieben und die Zeiten gemessen - QtSql: 0.5 s sqlite3: 0.5s ! Geschwindigkeitsmässig macht es also doch keinen Unterschied. Hatte wohl vorher mit "...where name=abc" und nicht mit "...where name like abc" getestet. Zweiteres dauert in beiden Versionen 5 Sekunden. Sorry, da habe ich was Falsches behauptet.

Nach weiterem Studium ist noch eine Frage hinzu gekommen: Kann ich denn in QtSql auch - wie in sqlite3 - Adapter registrieren und benutzen. Dazu habe ich nichts gefunden. Das ist für mich wichtig, zu wissen, weil ich auch serialisierte (oder halt adaptierte) Float-Daten-Arrays abspeichern möchte.

Auf der anderen Seite ist mir aber nach weiteren Recherchen klar geworden, dass ich mein Programm mit sqlite3 nicht so einfach auf andere Datenbanken umschreiben kann, weil Python selbst wohl nur SQLite unterstützt ? Inwieweit andere Adapter (wie hier zu Hauf aufgelistet) mit den gleichen Methoden zu programmieren sind wie mit sqlite3, weiss ich nicht.

Ich denke, dass da wohl Einiges eher für die QtSql-Lösung spricht ...
EyDu
User
Beiträge: 4881
Registriert: Donnerstag 20. Juli 2006, 23:06
Wohnort: Berlin

mephisto-online hat geschrieben:Auf der anderen Seite ist mir aber nach weiteren Recherchen klar geworden, dass ich mein Programm mit sqlite3 nicht so einfach auf andere Datenbanken umschreiben kann, weil Python selbst wohl nur SQLite unterstützt ?
Das ist Unsinn, es gibt sogar ein eigenes PEP zur Datenbank API und diverse Module, welche das für alle möglichen Datenbanken implementieren. Aber warum willst du die Arbeit überhaupt von Hand machen, du hast SQLAlchemy doch selbst erwähnt. Wenn keine Gründe dagegen sprechen, dann verwende das.
Das Leben ist wie ein Tennisball.
mephisto-online
User
Beiträge: 167
Registriert: Sonntag 29. September 2013, 17:05

Ja, Unsinn kann ich auch überhaupt nicht leiden ! Aber deshalb frage ich ja ! Stehe trotz jeder Menge lesens datenbankmässig auch noch ziemlich im Nebel. :oops:

Was dagegen sprechen könnte, ist vielleicht die häufig erwähnte "steile Lernkurve" bei SQLAlchemy. Oder ist das nicht so schlimm ? Und könnte mit SQLAlchemy dann nicht auch Camelot interessant sein, um es besser mit Qt zu verbinden ?

Nun gut, wenn sich das auch für meine relativ kleinen Datenbank-Anforderungen trotzdem lohnen würde und ich damit dann wirklich "datenbank-transparent" programmieren könnte, hätte ich kein Problem damit, mich auch damit zu befassen. Und, wie ich das bislang verstanden habe, würde ich damit auch ein wenig um SQL herumkommen (was ich ehrlich gesagt nicht so sehr mag) ?
mephisto-online
User
Beiträge: 167
Registriert: Sonntag 29. September 2013, 17:05

Ok, orientieren muss ich mich wohl ohne Eure Hilfe.

Ich bin an dem Punkt angekommen, dass ich wohl so Sachen wie Camelot (geht glaube ich eh nur mit python2) oder SqAlchemy nicht brauche, weil Programmiereffizienz bei mir nicht unbedingt eine Rolle spielt. Und von Bibliotheken über Bibliotheken stülpen halte ich auch nicht so viel.

Der Einfachheit halber werde ich wohl erst mal mit QtSql weitermachen, liebäugele aber weiterhin mit der datenbankmässigen Python-Reinkultur-Lösung.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

mephisto-online hat geschrieben: Der Einfachheit halber werde ich wohl erst mal mit QtSql weitermachen, liebäugele aber weiterhin mit der datenbankmässigen Python-Reinkultur-Lösung.
Wenn Du eh auf Qt setzt und das auch oder vor allem zur Anzeige von Daten nutzen magst (also QtGui), dann bietet es sich auf jeden Fall an, da Du dann Models "geschenkt" bekommst, die sich wunderbar in die View-Komponenten der MVC-Architektur von Qt einfügen. Hinzu kommt iirc lazy loading bspw. beim Scrollen in QListViews, was Du ansonsten alles selber bauen müsstest.

Und Deine Phobie bezüglich Bibliotheken-Bäumen solltest Du dringend überdenken... eigentlich ist das nämlich eine rein emotionale und künstliche Abneigung.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
mephisto-online
User
Beiträge: 167
Registriert: Sonntag 29. September 2013, 17:05

@Hyperion
Das ist ja mal ein Statement, mit dem ich was anfangen kann ! Danke !

Bei meinem Programm handelt es sich im wesentlichen um ein Qt-Programm mit Berechnungen aus Daten, die aus der Datenbank stammen und die ich in 3D-Widgets visualisieren möchte. Wenn das für einen Datensatz steht, möchte ich das Ganze auch mit Datenbank-Scans auswerten können (Record lesen -> "auspacken" (weil es sich um serialisierte Dicts mit Floats handelt) -> auswerten -> nächsten Datensatz lesen (irgendwann werden es Hunderte von Datensätzen sein). Da habe ich halt Angst, dass ich mit QtSql irgendwann in eine Sackgasse rennen könnte. Immerhin verwendet Qt ja eigene Datentypen, wobei ich nicht einschätzen kann, ob das überhaupt ein Problem sein könnte. Mir ist auch nicht ganz klar, ob ich mit QtSql ohne weiteres Serialisierungs-Methoden wie z.B pickle oder json benutzen kann. In den Qt-Bibliotheken selbst habe ich solche Methoden nicht gefunden.

Und ob das bei mir nun ne Bilbiothekenbaum-Phobie ist, da bin ich mir jetzt nicht so sicher. Wenn ich damit etwas machen kann, was ohne nicht geht, habe ich nämlich absolut keine Probleme damit.
Antworten