Das deutsche Python-Forum

Hi,
ich möchte eine Kunden- und Lagerverwaltung in Python schreiben. Als Datenbank verwende ich MySQL. Die Anwendung soll auch von mehreren Usern gleichzeitig genutzt werden können.

Ich überlege jetzt wie ich das angehe. Soll ich die komplette Anwendung in den Client Rechner packen und MySQL auf einen eigenen Server oder wäre es besser die Anwendung selbst in einen Client und Server aufzusplitten, also das der Client selbst eigentlich nur ein grafischer Frontend ist? Ließe sich dafür XML-RPC verwenden?

burli hat geschrieben:Ich überlege jetzt wie ich das angehe. Soll ich die komplette Anwendung in den Client Rechner packen und MySQL auf einen eigenen Server oder wäre es besser die Anwendung selbst in einen Client und Server aufzusplitten, also das der Client selbst eigentlich nur ein grafischer Frontend ist? Ließe sich dafür XML-RPC verwenden?

Eigenständiger Server, mit *RPC ist imho eine gute Wahl.
Nachteile bei der nur-Client/DB-Lösung wären mögliche Inkonsistenzen, wenn veraltete Clients installiert sind, und niedrigere Sicherheit (clients brauchen db-zugriff, server kann da feiner granulieren)

Den Server würde ich nicht nur aus MySQL bestehen lassen. Gründe: MySQL müsste nach Außen offen sein und du kannst das Backend für die Datenhaltung nicht ändern. Auch muss jeder Client die aktuellen Zugangsdaten kennen, mal eben ohne großen Aufwand das Passwort wechseln (sei es aus Regelmäßigkeit oder nach einem [realen, drohenden oder nicht ausgeschlossenen] Zwischenfall) fällt dann aus. Zudem ist es ein leichtes, mit den Zugangsdaten Schabernack zu treiben, die Datenbank zu manipulieren, schädigen oder eigentlich nicht freigegebene Inhalte auszulesen. Dazu kommt, dass die Verbindung im Normalfall meines Wissens komplett ungeschützt ist.

Wie wäre es mit einer Web-Applikation? Vorteile: Es muss keine Software auf den Clients installiert werden (Browser sind ja nicht erst seit gestern Teil eines jeden aktuellen Desktop-OS) und du hast allen Code auf dem Server, was Updates enorm vereinfacht. HTTPS sorgt für eine zusätzliche Absicherung der Übertragung.

Von Web Applications halte ich wenig. Dafür ist die Anwendung imho zu komplex

Definiere "komplex" für deinen Fall.

Y0Gi hat geschrieben:Definiere "komplex"

Definition von 'komplex' im Kontext 'Web'.

burli hat geschrieben:Von Web Applications halte ich wenig. Dafür ist die Anwendung imho zu komplex

Angesichts der Tatsache, dass es sowas von kommerziellen Anbietern bereits als Webanwendung gibt, würde ich das jetzt nicht unbedingt unterschreiben

Gibt es doch schon: http://www.tinyerp.org/index.html

Hallo burli!

Ich halte ziemlich viel von Datenbankanwendungen mit Client-Server-Architektur. Warum? Weil gute Datenbanken (ich meine jetzt nicht MySQL) einem die Arbeit sehr erleichtern können.

Arbeiten, die du nicht mehr eigens programmieren musst, wenn du ein gutes Datenbanksystem verwendest:

- Benutzeranmeldung
- Einteilung der Benutzer in Gruppen
- Überwachen der Zugriffsberechtigungen (nicht jeder darf gleich viel)
- Datenübermittlung (lokal und auch über das Netzwerk)
- Datenkonstistenz überwachen
- Unvollständige Transaktionen rückgängig machen
- Ausgeklügelte Suchanfragen (z.B. mit Unterabfragen)

Eine gute Datenbank nimmt einem viel Arbeit ab, um die man sich selber kümmern müsste, wenn man einen eigenen Server programmiert. Erst recht, bei solchen Aufgabenstellungen wie einer "Kunden-/Lagerverwaltung".

Überlege dir mal, welche Arbeiten dir ein Serverprogramm in deiner Anwendung abnehmen kann, die das Datenbanksystem nicht schon ausgeklügelter und vielleicht auch besser kann. Das wird nicht besonders viel sein.

Ich empfehle auf MySQL zu verzichten, PostgreSQL zu verwenden und direkt von den Clients aus auf die PostgreSQL-Datenbank zuzugreifen. Das ist schneller in der Anwendung und in der Programmierung und hat sich bereits seit vielen Jahren im Einsatz bewährt.

Programmiere so, dass du globale Module hast, die sich um den Datenbankzugriff kümmern und die Programmlogik enthalten. Diese Module kannst du dann in den verschiedensten Client-Programmen einsetzen. Nur weil du dann keine laufende Serveranwendung hast, heißt das noch lange nicht, dass du für jeden Client die Anwendung neu schreiben musst. Halte dich ein wenig an die Trennung in Datenbankschicht, Middleware und Client. Dann kannst du dein Programm jederzeit um z.B. eine Weboberfläche, eine andere GUI oder Automatisierungsschnittstelle erweitern.

mfg
Gerold

Hi Gerold,
was macht Postgresql anders/besser als MySQL?

burli hat geschrieben:was macht Postgresql anders/besser als MySQL?

Hallo burli!

Mit PostgreSQL kannst du Tabellen erstellen. Dann kannst du Tabellen untereinander in Beziehung stellen. Du kannst genau regeln, was passieren soll, wenn sich Daten, die miteinander in Beziehung stehen, ändern oder diese gelöscht werden.

Du kannst Prozeduren in der Sprache PL/PGSQL erstellen. Diese Sprache geht über das "normale" SQL hinaus. Man kann damit sogar Ergebnisse einer Abfrage durchlaufen, mit diesen Daten arbeiten, filtern, ändern, oder was auch immer und dann so zurück geben, dass der Client so damit arbeiten kann, als ob er einfach nur eine SQL-Abfrage ausgeführt hätte.

Man kann diese Prozeduren nicht nur in PL/PGSQL schreiben. Nein, mann kann auch Python als Serversprache einsetzen. Was ich bis jetzt aber noch nie gemacht habe.

Du kannst Tabellen partitionieren, so dass alte Daten, die selten gebraucht werden, in einem eigenen Speicherbereich liegen und nur dann mit eingebunden werden, wenn diese benötigt werden.

Du kannst Prozeduren definieren, die automatisch aufgerufen werden, wenn Daten einer Tabelle ausgewählt, gelöscht oder geändert werden. Habe ich schon erwähnt, dass diese Prozeduren auch in Python geschrieben werden können? Das bedeutet, dass du durch eine SQL-Abfrage eines deiner Clients z.B. ein Email vom Server aus verschicken lassen könntest.

Du kannst Regeln definieren, welche beim Hinzufügen oder Ändern von Daten prüfen ob die Daten diesen Regeln entsprechen.

Du hast Rollen zur Verfügung, welche du benutzen kannst um Benutzer und Gruppen zu erstellen und diesen Berechtigungen auf Tabellen zu geben. Diese Rollen kannst du auch für ein eigenes Berechtigungssystem verwenden, da du für jeden Benutzer (Rolle) dessen Zugehörigkeit abfragen kannst.

Als ersten Filter kannst du schon mal einstellen, welcher Computer auf welche Datenbanken zugreifen darf. Und ob auf die Datenbank nur lokal oder entfernt zugegriffen werden darf. Du hast mehrere Authentifizierungsmethoden zur Verfügung: Passwort, MD5, CRYPT, Kerberos, LDAP, PAM,...

Das SQL von PostgreSQL hält sich so gut wie möglich an Standards. In wie weit sich die möglichen SQL-Konstrukte (INNER, OUTER, LEFT OUTER, UNION, ...) von MySQL unterscheiden, kann ich dir nicht sagen. BEGIN TRANSACTION und COMMIT TRANSACTION haben bei PostgreSQL eine Wirkung. Bei MySQL braucht es einen speziellen Tabellentyp dafür. Aber bei den (meistgebrauchten) MyISAM-Tabellen von MySQL gibt es (glaube ich) keine Transaktionen.

Ausgabe von Ergebnissen in XML, Volltextsuche, Regular Expressions in SELECT-Abfragen, Views und temporäre Views, Transaktionen, Row Locking, Verschlüsselte Datenübertragung (SSL), ...

PostgreSQL ist ein Datenbanksystem, dem ich Daten anvertrauen kann. Das sich auch um die Integrität der Daten kümmern kann. Außerdem ist PostgreSQL schon seit vielen Jahren OpenSource. Ein freies Datenbanksystem, welches benutzt, weitergegeben und modifiziert werden darf, ohne dass ich mir vorher eine Lizenz kaufen muss.

Hier steht auch noch was: http://www.postgresql.org/about/

mfg
Gerold

Hi Gerold,
danke für die ausführliche Darstellung, aber es gibt ein paar Punkte die für mich gegen Postgresql sprechen. Am wichtigsten ist wohl: ich hab keine Ahnung von Postgresql und ich brauche auch Zugriff auf meine Webseite und da läuft eh MySQL. Und doppelt lernen will ich nicht unbedingt. Ich denke mit MySQL lässt sich das auch realisieren

tinyerp & co kenne ich. Überzeugt mich aber nicht richtig. Und sowas in HTML & co programmieren muss man auch erstmal können

Gerold, ich bin bei leibe kein Experte, was DBs angeht, aber hat sich MySQL inzwischen nicht auch weiter entwickelt? Constraints für cascaded deletes, trigger und stored procedures (allerdings nicht in Python) kann MySQL auch. Die Aufteilung der Tabellen einer Datenbank in Dateien (tables spaces) kann man ebenfalls beeinflussen. User und Gruppen mit unterschiedlichen Zugriffsrechten (inklusive Beschränkung der Rechner/IP) gibt es auch. Das MySQL verschiedene Tabellentypen mit verschiedenen Eigenschaften (Transaktionen ja/nein) hat, ist doch eher ein Vor- als ein Nachteil. Zu einem XML-Datentyp (wie ihn etwa Derby aka Sun DB hat) habe ich nichts gefunden, aber Volltextsuche kann MySQL wieder.

Zu MySQL hätte ich dann noch anzubieten, dass wahrscheinlich Facebook die weltgrößte Installation von MySQL betreibt - angeblich haben die mehr als 1.800 Datenbank-Server (und insgesamt mehr als 10.000 Server) im Einsatz.

PS: Ich würde bei der Aufgabenstellung eine Webanwendung als portabelste, am einfachsten installier- und verteilbare und erweiterbare Lösung ansehen - auch wenn sie vielleicht nicht so einfach zu realisieren ist.

Stefan

sma hat geschrieben:Zu MySQL hätte ich dann noch anzubieten, dass wahrscheinlich Facebook die weltgrößte Installation von MySQL betreibt - angeblich haben die mehr als 1.800 Datenbank-Server (und insgesamt mehr als 10.000 Server) im Einsatz.

Yahoo ist mit Postgres auch ganz gut dabei (mit Modifikationen, aber das ist bei Facebook warscheinlich auch nicht anders). Es kommen immer mal wieder Geschichten auf Reddit wie MySQL die Sicherheit von Daten nicht sicherstellt. Nichts gegen mehrere Datenbankbackends, aber das Problem ist, dass die brauchbaren Backends alle nicht MySQL AB gehören, sondern etwa Oracle und die irgendwie so in der Schwebe stehen. Daher schreibt MySQL AB jetzt an "Maria", womit sie ein brauchbares eigenes Backend bringen wollen,

sma hat geschrieben:Gerold, ich bin bei leibe kein Experte, was DBs angeht, aber hat sich MySQL inzwischen nicht auch weiter entwickelt?

Hallo Stefan!

Ich bin Experte für Microsoft SQL-Server und langsam (seit ein paar Jahren) entwickle ich mich auch in Richtung PostgreSQL weiter.

Als ich eine Alternative zum MS SQL-Server suchte, informierte ich mich über die Vor- und Nachteile einiger Datenbanksysteme. Was mir beim MySQL-Server bitter hochstieß, war dass manche (vielleicht auch gute) Tabellentypen damals unter einer Lizenz standen, die nicht mit meinen damaligen Zielen vereinbar waren. Und MyISAM ist für Projekte, die Datensicherheit voraussetzen, auch heute noch nicht geeignet.
Außerdem habe ich es alle paar Monate mit MySQL-Datenbanken (mit MyISAM-Tabellen) zu tun, die nicht mehr konstistent sind, und muss beim Übernehmen der Daten die Datenbestände oft händisch nachbessern oder auch Datenverluste in Kauf nehmen.

Damals gab es noch keine Prozeduren in MySQL und das ist ein großes Manko wenn man die zusätzliche Power von gespeicherten Prozeduren kennengelernt hat. Denn eines ist bei einem zentralen Datenbankserver ziemlich wichtig: Je besser man die Daten bereits im Server filtern und vorbereiten kann, desto weniger Daten müssen über das Netz geschickt werden. Und das Netzwerk ist meist der dünnste Flaschenhals im System. Außerdem kann man mit gespeicherten Prozeduren, große SQL-Anweisungen zusammenfassen. So überträgt der Client nicht mehr bei jedem Aufruf die ganze, lange SQL-Anweisung, sondern nur mehr den Aufruf einer Prozedur. Was sich bei sich oft wiederholenden Szenarien sehr schnell rentiert.

Ja, natürlich hat sich MySQL in der Zwischenzeit weiterentwickelt. Wie weit diese Entwicklung fortgeschritten ist, kann ich nicht sagen, da ich mich seit Jahren nicht mehr damit auseinandergesetzt habe. Vor ein paar Jahren war zumindest PostgreSQL der klare Favorit für mich. PostgreSQL bot damals schon annähernd gleich viel Komfort wie der MS SQL-Server. Inzwischen hat sich PostgreSQL sehr in Richtung Oracle weiterentwickelt.

Persönliche Meinung: Ich glaube, dass PostgreSQL für einen "Datenbankprogrammierer" immer noch die bessere Wahl ist. So schnell kann MySQL gar nicht aufholen, denn PostgreSQL entwickelt sich ja auch ständig weiter.

Allerdings muss ich auch dazu sagen, dass PostgreSQL einem nur dann etwas bringt, wenn man sich mit dessen Features auseinandersetzt und sie einsetzt.

Wer einfach nur einen Speicherplatz für seine Daten sucht und alles im Programm macht, für den bietet PostgreSQL kaum mehr oder weniger Vorteile als MySQL. Wer so programmiert, darf sich aber auch nicht wundern, wenn die Performance mit zunehmender Datenmenge einknickt. Richtige Datenbankprogrammierung rentiert sich immer dann, wenn man es mit sehr vielen Daten zu tun hat. Damit meine ich "Millionen", nicht nur "Tausende".

Ich will mich mit niemandem anlegen. Wer MySQL für leistungsfähiger oder besser hält, kann damit Recht haben. Ich weiß es nicht.

mfg
Gerold

MySQL kann mittlerweile Views, Trigger, Stored Procedures, Transactions und einiges mehr. Was mich allerdings stört: MyISAM kann Volltextsuche, aber keine Transactions, InnoDB kann Transactions, aber keine Volltextsuche (es sei denn da hat sich inzwischen was geändert)

Aber Lizenz, Sicherheit oder Features hin oder her, weil ich durch meinen Webspace an MySQL gebunden bin werde ich als lokale Datenbank auch MySQL verwenden

burli hat geschrieben:Aber Lizenz, Sicherheit oder Features hin oder her, weil ich durch meinen Webspace an MySQL gebunden bin werde ich als lokale Datenbank auch MySQL verwenden

Die eigentliche Frage ist hier nicht die Bindung, sondern was dir deine Nerven und die Zeit wert ist. (V)Hosts gibts schon für < 10€/Monat, und da kannst du alle Tools/Bibliotheken/Datenbanken installieren, die dir Zeit sparen.

Damit der Preis eines Webspaces ein Argument ist, muss dein (fiktiver) Stundenlohn ziemlich nahe null sein.

Ich bezweifle das ich das Webscript, das derzeit mit MySQL arbeitet, so ohne weiteres auf Postgresql portieren kann. Ich denke es dauert länger zuerst Postgresql zu lernen, dann das Script zu portieren und zuletzt die Anwendung zu schreiben als gleich die Anwendung mit MySQL zu programmieren

burli hat geschrieben:Webscript, das derzeit mit MySQL arbeitet

Hallo burli!

Unabhängig von der Datenbank die du für dein Projekt einsetzt. Ist es nicht so, dass man bei den meisten Providern nicht von einem anderen Computer als direkt vom Webserver aus (local) auf die MySQL-Datenbanken zugreifen kann? Kannst du von deinem Computer aus, direkt auf die MySQL-Datenbank deines Providers zugreifen?

Wenn nicht, dann fällt diese Bindung schon mal weg. Außerdem ähnelt das SQL von MySQL dem von PostgreSQL. Eine Portierung einer kleinen Anwendung ist nicht das Problem. Aber mein Tipp war nicht, "PostgreSQL" für eine Webanwendung zu verwenden. Mit Tipp bezog sich auf die von dir geschilderte Anwendung: Eine Kundenverwaltung und Warenwirtschaft mit verteilen Clients, die alle auf eine Datenbank zugreifen müssen. So etwas macht man nicht mit einer vom Provider eingeschränkten Datenbank. Lässt der Provider überhaupt zu, dass du einen anderen Tabellentyp als MyISAM verwendest? Da kenne ich auch ein paar, die das einschränken.

Dann frage ich mich noch, was die Datenbank deines Providers mit deinem Programm zu tun hat. Wenn du **Kundendaten** und Daten von **Waren** ungeschützt übers Netz überträgst, handelst du fahrlässig. Außerdem weißt du nie, wer über welche Hintertürchen auf die Datenbank zugreifen kann. Also der Provider "kann", denn der sitzt ja direkt auf dem Computer.

So eine Datenbank gehört auf einen Computer den du kontrollieren kannst. Weiters sollte die Netzverbindung verschlüsselt werden. Z.B. mit OpenVPN. Damit scheidet auch ein V-Server bei einem Provider aus. Denn die können erstens überwacht werden und zweitens (aus technischen Gründen) keine OpenVPN-Verbindung aufbauen. OK, SSH würde als Tunnel funktionieren.

Wenn du Daten übers Internet veröffentlichen möchtest, dann könntest du von deinem Datenbankserver (der nicht beim Provider liegt) aus, die benötigten Daten zum Internetserver hochschieben. Dann verlassen dein System nur die Daten die sowiso veröffentlicht werden.

Um mehr dazu schreiben zu können, müsste man mehr über dein Projekt wissen.

mfg
Gerold

Um das aufzudröseln:
Bei der Webseite handelt es sich um einen Webshop
Ja, ich kann remote auf die DB von meinem Provider zugreifen.
Für die Kundendaten usw wird eine zweite Datenbank auf einem lokalen Rechner installiert der nicht aus dem Internet erreichbar ist..

Die Verbindung zum Provider läuft über SSL und dient eigentlich nur dazu um den lokalen Artikelstamm mit dem auf er Webseite abzugleichen.

Ich achte schon auf Sicherheit, aber die absolute Sicherheit gibt es nicht.