Welche SQL-Datenbank für Python3?

[krautbert]

Nabend Leute,

ich bin zur Zeit fleißig am Python lernen und total begeistert von der Programmiersprache.
Ich habe vor demnächst, wenn das nötige KnowHow vorhanden ist, ein Programm zu schreiben welches mit einer zentralen Datenbank kommuniziert. Sprich: Dort Daten reinschreibt und ausließt.
Jetzt Frage ich mich, mit welcher SQL-Datenbank kann Python3 am besten kommunizieren?
MySQL wäre mein Favorit. Allerdings stößt das auf Verwunderung, da diese eher für den Bereich Webserver bekannt ist.
Was denk ihr? Welche Datenbank passt am besten zu Python3? Wo kann es eventuell Probleme geben und wo kann man sonst noch seinen Senf dazugeben?
PS: Das Programm sollte auf Windows-Clients laufen.

Grüße Krautbert

[Manchotix]

Also jede Datenbank passt zu Python 3 .... ich denke mal das kommt drauf an was man machen will.
Bei meiner Linux Distro wird bei Python sofort die DB-lang Sqlite3 mit Installiert und ist für kleine Sachen und für denn Anfang richtig gut (ich komme da mit ganz gut zurecht ;D )
Aber es gibt ja so viele DBs z.B. MongoDB, PQSQL, MariaDB, MySQL, SqLite3, CouchDB etc. und Python hat zu vielen eine Anbindung.

[BlackJack]

@krautbert: Pack SQLAlchemy als Abstraktionsschicht dazwischen. Dann kannst Du die Datenbank einfach austauschen.

[/me]

MySQL wäre mein Favorit. Allerdings stößt das auf Verwunderung, da diese eher für den Bereich Webserver bekannt ist.

Ich habe Python bisher mit SQLite, MariaDB (bzw. früher MySQL), PostgreSQL und Oracle eingesetzt. Wenn du richtig Last auf dem System hast, dann würde ich SQLite allerdings ausschließen.

Der von BlackJack angesprochene Abstraktionslayer ist auf jeden Fall eine gute Idee. Ich persönlich komme allerdings aus dem DB-Bereich und empfinde klassische SQL-Kommandos als leichter lesbar und handlicher, auch wenn ich beispielsweise im Kontext von Django natürlich den objektrelationalen Mapper einsetze.

[DasIch]

MySQL wäre mein Favorit. Allerdings stößt das auf Verwunderung, da diese eher für den Bereich Webserver bekannt ist.

Der von BlackJack angesprochene Abstraktionslayer ist auf jeden Fall eine gute Idee. Ich persönlich komme allerdings aus dem DB-Bereich und empfinde klassische SQL-Kommandos als leichter lesbar und handlicher, auch wenn ich beispielsweise im Kontext von Django natürlich den objektrelationalen Mapper einsetze.

Man muss bei SQLAlchemy ja nicht zum ORM greifen, die SQL Expression Language bietet dir auch schon viele Vorteile und entfernt sich nicht sonderlich weit von SQL selber schreiben.

[Zennoe]

SQLite hat den Nachteil beim Schreiben von Einträgen nicht erreichbar zu sein. Wenn du z.B. ein Vokabellern-Programm lokal laufen lässt, ist das kein Problem. Wenn du aber ein großes Forum, wie python-forum.de laufen lassen willst, wo viele Zugriffe und Änderungen vorgenommen werden, empfehle ich MySQL.
Allerdings muss MySQL entweder mit einem Webserver oder komplett als eigener Prozess laufen. SQLite hingegen muss nur auf eine Datei zu greifen. Und für SQLite brauchst du auch nur die entsprechende Python-Standardbibiliothek zu importieren.

[DasIch]

Wieso sollte man MySQL nehmen wenn Postgres existiert und man die Möglichkeit hat es zu nutzen? MySQL mag ja viele Dinge sein aber empfehlenswert fällt sicherlich nicht darunter.

[krautbert]

Vielen Dank für die ganzen Antworten!

MySQL mag ja viele Dinge sein aber empfehlenswert fällt sicherlich nicht darunter.

Wieso?

Mein Ziel ist, zentral einen Datenbankserver laufen zu haben auf den mehrere Client auf einmal zugreifen und reinschreiben sollen.
Ich habe heute mal ein wenig rumgelesen und mich eigentlich für MySQL mit nem mysql.connector Modul entschieden. Das scheint mir alles sehr rubust...!?
Was meint ihr?

Grüße!

[Hyperion]

MySQL mag ja viele Dinge sein aber empfehlenswert fällt sicherlich nicht darunter.

Wieso?

- Naja, es steht unter der Fuchtel von Oracle - das hat Java bisher auch weniger gut getan, analoges gilt für Open Office...

- MySQL setzt im Backend-Bereich auf verschiedene Storage-Engines; je nach Wahl, handelt man sich gewisse Vor- und Nachteile ein. Postgres z.B. ist aus "einem Guss", d.h. man muss sich nicht für etwas entscheiden, von dem man anfänglich keine Ahnung bezüglic der Konsequenzen hat. Oder wüsstest Du auf Anhieb, ob Du nun MyIsam, InnoDB oder sonst etwas wählen solltest (Ok, man *sollte* InnoDB wählen, da man sonst kein echtes RDBMS vor sich hat, aber das kann man als Anfänger kaum entscheiden).

- Bei MySQL bricht die Community auseinander, da der ehemalige Hauptentwickler das ganze geforkt hat und nun mehr an diesem, namentlich MariaDB, arbeitet.

Vermutlich gibt es derer noch viele

Für MySQL spricht hingegen, dass es bei den üblichen WebHostern weit verbreitet ist. Letztlich sollte das aber keine große Rolle spielen, sofern Du kein Produkt entwickeln willst, was für möglichst viele andere einfach deploybar sein soll... für Dich alleine findest Du genauso Webhoster, die Postgres anbieten! Und während der Entwicklung brauchst Du eh noch keinen externen Hoster...

Ich würde eigentlich immer versuchen, möglichst DB unabhängig zu entwickeln und mich eben *nicht* an *ein* System zu binden. Zum einen lagert man dann nicht so viel in SQL aus (find ich eh doof! ), um damit nicht zu viel spezielles, schlecht portierbares Zeug eines RDBMS zu nutzen, zum anderen entwickelt man einen schärferen Blick dafür, Domänen-Schicht und Datenzugriffsschicht besser zu trennen (nicht zuletzt, weil man nicht direkt SQL im Code schreibt, sondern eine Abstraktionslib dazwischen hat).

[krautbert]

Vielen Dank für die ausführliche Erklärung. Das gibt mir natürlich zu denken...
Ich denke, dass tendiert alles in richtung SQLAlchemy.
Dann werde ich mich die Tage eingehender damit beschäftigen.
Gibt es da noch etwas wichtiges zu beachten? Ich denke doch, dass dieses toll als stabil gilt...?!

Grüße!