Suche Buch über Python und SQL

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Donnerstag 27. November 2008, 18:18

cajus hat geschrieben:
Leonidas hat geschrieben:Wie gesagt, SQL nutzt man in Python so oder so nicht. SQL-Kenntnisse werden dir sicherlich nicht schaden, aber wirklich brauchen tust du sie nicht.
Ich meinte dies für webscripts,nicht für offlineprogramme.
Ja, wie die anderen schon gemeint haben: auch für Webscripts braucht man idR keine bis kaum SQL-Kenntnisse.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
farid
User
Beiträge: 95
Registriert: Mittwoch 8. Oktober 2008, 15:37

Freitag 28. November 2008, 10:24

derdon hat geschrieben:Ob du lieber plain SQL oder mit einem ORM programmierst, musst du aber selber entschieden.
Das ist schon richtig. Ich finde aber, daß SQL etwas mehr low-level ist als ORM zu benutzen. Schließlich gibt es subtile und nicht-ganz-so-subtile Unterschiede zwischen diversen SQL-Dialekten, und ein gutes ORM wie sqlalchemy kann diese Unterschiede weitgehend ausblenden. Das kann die Portierung von Projekten von einem RDBMS zum anderen doch erheblich vereinfachen.
burli
User
Beiträge: 1116
Registriert: Dienstag 9. März 2004, 18:22

Freitag 28. November 2008, 10:55

Um auf das Topic nochmal zu Antworten: Ein Buch über Python und SQL ist glaube ich unnötig. Alles was man braucht ist ein Buch über SQL. Wie man SQL von Python aus verwendet ist mit wenigen Sätzen erklärt.

Wenn man die Daten in einem GUI Toolkit anzeigen will ist das eher Sache des Toolkits als die von Python (um genau zu sein die des Bindings) wie das gehandhabt wird. Das würde ein einzelnes Buch glaub ich sprengen.

Ob ein ORM in jedem Fall vorzuziehen ist weiß ich nicht. Ich sehe noch nicht den ultimativen Vorteil eines ORM. Für meinen Geschmack wird das zu stark abstrahiert und man verliert die Kontrolle über die Datenbank. Vor allem habe ich Bedenken was die Performance und die Optimierungsmöglichkeiten angeht. Ich weiß nicht ob und wie es möglich ist zb Trigger oder Stored Procedures zu verwenden.

Unabhängig davon, ob man ein ORM verwendet oder nicht, würde ich mir zumindest ANSI SQL aneignen. Das sollte jede Datenbank verstehen.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Freitag 28. November 2008, 12:28

burli hat geschrieben:Ob ein ORM in jedem Fall vorzuziehen ist weiß ich nicht. Ich sehe noch nicht den ultimativen Vorteil eines ORM. Für meinen Geschmack wird das zu stark abstrahiert und man verliert die Kontrolle über die Datenbank. Vor allem habe ich Bedenken was die Performance und die Optimierungsmöglichkeiten angeht. Ich weiß nicht ob und wie es möglich ist zb Trigger oder Stored Procedures zu verwenden.
Hallo!

Ich bin voll burlis Meinung. Ein gutes Datenbanksystem bietet mehr als nur das einfache Abspeichern und Wiederfinden von Daten.
Ein gutes Datenbanksystem kann man so verwenden, dass so wenig Daten wie nötig über das langsame Netzwerk geschickt werden. Und das ist bei verteilten Anwendungen das Um und Auf.
Weiters bietet ein Datenbanksystem wie PostgreSQL eine Benutzerverwaltung mit Rechtevergabe, Gruppen, Benutzern usw. So kann man als Anwendungsentwickler auf ein bereits fertiges Authentifizierungssystem und Berechtigungssystem zugreifen.
Durch Beziehungen zwischen den Daten/Tabellen, werden Datenleichen vermieden. Durch gezieltes Indizieren der Daten werden Suchanfragen beschleunigt. OK, das können die meisten ORMs auch.

Aber wo ORMs total auf die Schnauze fallen: Das Erstellen von temporären Tabellen, Befüllen dieser Tabellen mit gefilterten Daten, nachträglichem Indizieren dieser Tabellen und abschließendem Abfragen der gewünschten Daten aus diesen vorgefilterten Tabellen. Das ist nämlich etwas, was auch bei meinen (großen) Datenbankanwendungen extreme Geschwindigkeitszuwächse bringt. Statt einer Abfragelaufzeit von zwei Stunden, sind so Laufzeiten von wenigen Minuten herauszuholen. Besonders bei großen Datenbanken mit z.B. Verkaufsdaten, Rechnungen, Lieferscheinen, Artikelbewegungsdaten usw.

Ich sage ja nicht, dass ORMs eine große Erleichterung sein können. Kleine und mittlere (subjektiv gesehen) Anwendungen lassen sich damit sicher einfach erstellen. Überhaupt für jemanden, der mit SQL noch nichts zu tun hatte, dürfte das eine Erleichterung sein. Aber wenn jemand die gleiche Energie in das Lernen von SQL steckt, die er/sie für das Erlernen des ORMs braucht, dann kommt man, meines Erachtens, mit SQL weiter. Denn mit SQL lassen sich kleine, mittlere und auch große Anwendungen schreiben. Anwendungen, die nicht nur lokal oder auf einem Webserver laufen, sondern auch verteilte Anwendungen, die auf eine gemeinsame globale Datenbank zugreifen müssen. Anwendungen, die die Arbeitsdaten in einer lokalen Datenbank cachen und die aktuellsten Daten in einer zentralen Datenbank verwalten.

Unabhängig davon was ich bis jetzt geschildert habe, gibt es ja noch mehr, was einem eine Datenbank bietet. Z.B. kann man Regeln definieren um die Daten zu prüfen, bevor diese auf die Festplatte geschrieben werden. So kann mit einfachen Datenbankregeln geprüft werden, ob z.B. ein gewisser unrealistischer Betrag überschritten wird, oder ob das Geburtsdatum eines neugeborenen Babys auch wirklich realistisch ist. So etwas ist eine praktische Prüfung auf Datenebene. Z.B. wird auf diese Weise global vor Fehleingaben gewarnt. Wenn man nicht nur selbst auf die Daten zugreifen muss, wenn mehrere Entwickler und/oder mehrere verschiedene Clientprogramme im Spiel sind, dann ist so eine zentrale Plausibilitätsprüfung der Daten Gold wert.
Manche werden jetzt einwenden, dass man ja eine Middleware schreiben kann, die einzig auf die Datenbank zugreifen darf. Und alle Clients müssen über diese Middleware gehen. Aber in der Praxis ist das oft nicht oder nur mit erhöhtem Programmieraufwand machbar. Was ist, z.B. wenn ein Manager bestimmte Auswertungen braucht? Dann greift man normalerweise mit einem Werkzeug wie Crystal Reports, Report Manager oder BIRT direkt auf die Datenbank zu. Oder zum Aufbauen von Datawarehouse-Anwendungen (sammeln von Daten zur vereinfachten zusammengefassten Auswertung). Für so etwas gibt es Anwendungen, die direkt auf die Datenbanken zugreifen. Man kann auch nicht ausschließen, dass irgendwann mal jemand direkt in die Datenbank schreibt oder dort Änderungen durchführt, die das ganze System durcheinander bringen können. Das kann mit Access, OpenOffice.org, oder irgend einem anderen Tool ohne Weiteres gemacht werden.

Aber um wieder auf den Punkt "Geschwindigkeit" zurück zu kommen. Es gibt ja noch mehr Dinge, die man ausnutzen kann um Datenbankanwendungen schneller zu machen. Z.B. kann man Sichten (vorgefertigte Abfragen) definieren. Diese sind dann in der Datenbank bereits vorkompiliert und müssen nicht bei jeder Anfrage neu aufbereitet werden. Manche Datenbanken bieten es sogar an, dass diese Sichten indiziert werden können. Dann hat man schon vorkompilierte Abfragen mit Indizes, die die Abfragen schneller machen.

Einen Geschwindigkeitsvorteil konnte ich z.B. beim Einsatz von "Gespeicherten Prozeduren/Funktionen" feststellen. Diese stellen, wie die Sichten, eine vorkompilierte Abfrage dar. Der Unterschied ist, dass man an diese Prozeduren auch Parameter übergeben kann und dass die Sprache in der solche Prozeduren/Funktionen erstellt werden können, meist mächtiger als das normale SQL ist. Wenn es in enormen Maße auf Geschwindigkeit ankommt, dann kann man unter PostgreSQL solche Funktionen sogar in C schreiben. Wenn die Geschwindigkeit nicht so wichtig ist, dann können solche Datenbankfunktionen sogar mit Python, Java oder TCL geschrieben werden. Über die Geschwindigkeitsunterschiede kann ich jetzt nur mutmaßen, da ich sie nie miteinander verglichen habe.

Trigger: Damit kann man Anweisungen ausführen lassen, wenn Daten in eine Tabelle geschrieben, aus dieser Tabelle gelöscht, oder wenn die Daten einer Tabelle verändert werden. Natürlich könnte man das auch in einer Middleware machen. Aber wenn man diese Aufgabe an die Datenbank bindet, dann ist die Datenintegrität eine Spur sicherer. Denn die Datenbank kann nicht so einfach übergangen werden. Die Middleware schon.
Für was könnte so ein Trigger gut sein? Hier ein Beispiel aus meiner aktuellen Anwendung: Eine Bestellung besteht aus vielen Bestelldetails (Artikel). Es werden einzelne Artikel aus mehreren Bestellungen zu Lieferscheinen zusammengefasst. Und erst dann, wenn alle Bestelldetails auf irgendeinem Lieferschein sind, gilt die Bestellung als "ausgeliefert". Trigger kümmern sich beim Erstellen der Lieferscheine darum, dass die zugehörigen Bestellungen entsprechend markiert werden. Diese Markierung ist wichtig, um spätere Auswertungen zu beschleunigen. Löscht/storniert man eine Lieferung, dann wird die Markierung für die betreffenden Bestellungen wieder zurückgesetzt. Da die Datenbank sich darum kümmert, kann kein Programm diesen Mechanismus unabsichtlich umgehen. Die Datenintegrität bleibt sichergestellt.

Ich könnte noch viel mehr darüber schreiben, welche Aufgaben eine gute Datenbank einem Programmierer abnehmen kann, die von einem ORM schlicht nicht durchgereicht werden können. Aber ich muss mich jetzt ums Brötchenverdienen kümmern und ein wenig an der Datenbankstruktur eines firmeninternen Bestellwesens für eine Großkonditorei feilen. ;-)

Ich glaube, dass man nicht einfach so behaupten sollte, dass man mit Python kein SQL mehr braucht. Es kommt immer auf die Anwendung an. Wenn einem eine Datenbank Arbeit abnehmen kann, dann sollte man mit dieser Datenbank arbeiten und nicht eine Abstraktionsschicht dazwischen schieben. Ich finde, dass ORMs vielleicht interessant sind, für reine Desktopanwendungen oder Internetanwendungen, die auf einem Webserver laufen. Da ist auch das Argument, dass man damit ohne Umstellung mit mehren Datenbanksystemen arbeiten kann, begründet. Aber wenn man typische Client-Server-Anwendungen schreibt, dann sollte man sich gut überlegen, ob man mit einem ORM die Funktionen der Datenbank aussperren möchte, die das Programmieren von Client-Server-Anwendungen so viel einfacher machen. Datenbanksysteme wie z.B. PostgreSQL sind hauptsächlich dafür geschaffen, um mehreren (auch verschiedenen) Clientsystemen Zugriff auf einen zentralen Datenbestand zu bieten. Und genau dafür bieten sie Funktionen wie Benutzerverwaltung, Authentifizierung, Berechtigungsverwaltung, Transaktionen, Row-Locking, Page-Locking, Table-Locking, und noch viel mehr.

lg
Gerold
:-)

PS: Entschuldigt, dass ich so viel geschrieben habe.
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
burli
User
Beiträge: 1116
Registriert: Dienstag 9. März 2004, 18:22

Freitag 28. November 2008, 13:11

Ich habe mich noch nicht intensiv mit ORMs beschäftigt, deshalb will ich mich nicht zu weit aus dem Fenster lehnen und behaupten, das sowas alles nicht geht.

Aber ich fühle mich einfach wohler wenn ich weiß was im Hintergrund passiert. Und mal ehrlich, wie oft kommt es vor das man die Datenbank wechselt? Ich werde vorerst bei MySQL bleiben weil ich bei meinem Provider nur MySQL zur Verfügung habe und ich nicht zweigleisig fahren will.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Freitag 28. November 2008, 13:27

burli hat geschrieben:deshalb will ich mich nicht zu weit aus dem Fenster lehnen und behaupten, das sowas alles nicht geht
Hallo burli!

Wie man hier http://www.sqlalchemy.org/docs/05/ormtu ... ying_using und hier http://www.sqlalchemy.org/docs/05/sqlex ... l#sql_text sieht, kann man mit SQLAlchemy, SQL-Anweisungen auch an die DB durchreichen. Die Verwendung von SQLAlchemy und das direkte Ansprechen der Datenbank ist in Kombination möglich.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
burli
User
Beiträge: 1116
Registriert: Dienstag 9. März 2004, 18:22

Freitag 28. November 2008, 13:33

Hi Gerold,
gut, möglich ist es, aber in dem Moment verliert man doch den Vorteil, das die Anwendung unabhängig von der Datenbank ist.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Freitag 28. November 2008, 13:54

burli hat geschrieben:möglich ist es, aber in dem Moment verliert man doch den Vorteil, das die Anwendung unabhängig von der Datenbank ist.
Hallo burli!

Ich finde, das ist ein Pluspunkt für SQLAlchemy. Auch wenn ich den ganzen Rest überladen und kompliziert finde. Und wenn wir ehrlich sind, dann kommt es überaus selten vor, dass man die Datenbank wechseln muss. Und wenn es wirklich der Fall sein sollte, dass die Datenbank unbedingt gewechselt werden muss, dann ist die Änderung an den SQL-Anweisungen selten so kompliziert, dass man lange für diese Änderungen brauchen würde. Außnahmen bestätigen hier natürlich die Regel. ;-)

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Freitag 28. November 2008, 13:58

gerold hat geschrieben:Aber wo ORMs total auf die Schnauze fallen: Das Erstellen von temporären Tabellen
Geht in SQLAlchemy durchaus.
gerold hat geschrieben:Anwendungen, die nicht nur lokal oder auf einem Webserver laufen, sondern auch verteilte Anwendungen, die auf eine gemeinsame globale Datenbank zugreifen müssen. Anwendungen, die die Arbeitsdaten in einer lokalen Datenbank cachen und die aktuellsten Daten in einer zentralen Datenbank verwalten.
SQLAlchemy unterstützt Sharding. Ich weiß allerdings nicht ob der OP jetzt mit seinen Applikationen ein Multi-DB-Cluster abfragen will, scheint mir persönlich etwas unverhältnismäßig.
gerold hat geschrieben:Manche werden jetzt einwenden, dass man ja eine Middleware schreiben kann, die einzig auf die Datenbank zugreifen darf.
Ja, es ist ein Thema zur Diskussion ob man die Datenbanklogik in der Datenbank hält oder im Client, beides hat vor und Nachteile. Aber der Einsatz eines ORMs schließt wohl kaum Stored Procedures oder Trigger aus, wenn man sie braucht kann man sie definieren.

Ich denke, es geht auch um verhältnismäßigkeit. Ab welcher größe von Applikationen macht es sinn SQL zu nutzen. Für die üblichen Blogs, Portale etc. ist SQLAlchemy durchaus ausreichend (448 User parallel, 94 Kilouser und viele Diskussionsthreads). Wie oft baut man Sachen die größer sind? Ist Python für sowas überhaupt noch die richtige Sprache?

Hier noch ein Ausschnitt aus dem IRC-Chatlog, wo __doc__ erklärt, warum er nicht SQL direkt nutzt.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Freitag 28. November 2008, 15:14

Leonidas hat geschrieben:(448 User parallel, 94 Kilouser und viele Diskussionsthreads)
Hallo Leonidas!

Die Frage ist nur, wie viel man da durch SQLAlchemy gewinnt.

Ich empfinde die DB-Api von Python als wunderbar einfach.
Verbinden -- SQL-Anweisung absetzen -- Ergebnis durchlaufen -- Verbindung trennen.
Man muss sich keine komplizierten Befehle merken. Alles passiert auf die gleiche Art und Weise. Und wem es zu kompliziert ist, sich die SQL-Anweisung selbst auszudenken, dem ist es wahrscheinlich auch mit einem ORM zu kompliziert. Der Unterschied ist der, dass man beim reinen SQL genügend Programme zur Verfügung hat, die einem dabei helfen, so eine SQL-Anweisung zusammenzusetzen. Ich erinnere nur mal an Access oder an Visual Studio. Aber auch wenn es nicht ideal funktioniert, auch mit OpenOffice.org kann man sich solche SQL-Anweisungen zusammenstellen.
Diese fertigen SQL-Anweisungen fügt man dann noch in den Python-Code ein und schon läuft die Anwendung.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Freitag 28. November 2008, 15:29

gerold hat geschrieben:Die Frage ist nur, wie viel man da durch SQLAlchemy gewinnt.
Hast du den IRC-Log gelesen? Dort steht was man in SQLAlchemy ohne ORM gegenüber DB-API gewinnt. Beim ORM kommen dann noch weitere Vereinfachungen die eben gerade bei so CRUD-Sachen nützlich sind.
gerold hat geschrieben:Verbinden -- SQL-Anweisung absetzen -- Ergebnis durchlaufen -- Verbindung trennen.
Macht man so in Webapps wie Inyoka oder das was ich so mit Django mache nicht. Da hat man persistente Verbindungen und Connection Pools, SQLAlchemy bietet da noch ein gewisses Caching und Django lazyness.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Freitag 28. November 2008, 15:34

Leonidas hat geschrieben:
gerold hat geschrieben:Verbinden -- SQL-Anweisung absetzen -- Ergebnis durchlaufen -- Verbindung trennen.
[...]Da hat man persistente Verbindungen und Connection Pools
Hallo Leonidas!

Ich habe das nur vereinfacht dargestellt. Natürlich würde niemand eine performante Anwendung schreiben können, wenn man für jede Abfrage eine neue Verbindung zur Datenbank aufbaut.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Freitag 28. November 2008, 15:38

Leonidas hat geschrieben:Hast du den IRC-Log gelesen? Dort steht was man in SQLAlchemy ohne ORM gegenüber DB-API gewinnt.
Hallo Leonidas!

Ich habe es mir durchgelesen. Der Punkt ist der, dass für mich SQL einfacher ist als die Syntax von SQLAlchemy. Deshalb kann ich das nicht nachvollziehen. Und wie ich schon schrieb, gibt es genug Programme, die das Erstellen von SQL-Anweisungen so einfach machen wie Milch drinken.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Sonntag 30. November 2008, 12:59

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.
Antworten