Open Source Web-Anwendung (ERP)

Hawelka · Montag 31. Oktober 2005, 18:27

Hallo Forum!

Ich entwickle seit rund 15 Jahren Anwendungen für den Bereich Handel (ERP, CRM) und in den letzten Jahren fast nur noch auf Web-Basis.
Vielleicht kennt jemand von euch Progress 4GL. War und ist jenes (kommerzielle) Entwicklungsumfeld, unter dem ich als selbstständiger Entwickler tätig bin.

Seit rund zwei Jahren beschäftigt mich der Gedanke, ein Open-Source Warenwirtschaftssystem zu entwicklen.
Ich bin jetzt zumindest so weit, daß ich mich auf Python und PostgreSQL festgelegt hab.

Worum ich die Pythoniker hier bitten möchte, ist, mir ein wenig auf die Sprünge zu helfen, bei der Entscheidung des Frameworks bzw. der darunter liegenden Technik.

Mir geht es dabei um zwei Aspekte:

- PostgreSQL-Adapter
Ich würde gerne (naiv forumliert), ein DB-Feld als Objekt betrachen können. Z.Bsp.: database.table.field = value.
Ich möchte aber dennoch "reines" SQL anwenden können.
Ist dies ein Wiederspruch?

- Webserver-Kommunikation
Von "lighttpd/fastcgi/WSGI" über "CherryPython/web-server" bis hin zu "zope" findet man eine Menge Möglichkeiten
Wichtig ist mir bloß, daß es einen Applikation-Server gibt, der einen HTTP-Request entgegennimmt, ohne daß er erneut die DB connecten muß.

Falls jemand selbst Erfahrungen in dieser Richtung hat, wäre es schön, wenn er/sie was dazu sagen könnte.

Danke im Voraus!
Hawelka

Gast · Montag 31. Oktober 2005, 19:18

Hi!

Hawelka hat geschrieben:und PostgreSQL festgelegt hab.

Ganz allgemeine bemerkung: das wäre das letzte was ich täte. Wenn schon "reines" SQL zum einsatz kommt, sollte das ganze auch offen für alle sql-dbs sein, die python unterstützt. Und eine installation zu testzwecken mit einem eventuell schon mitgelieferten sqlite wird mit sicherheit eher durchgeführt, als eine bei der man noch extra postgresql installieren muss, zumal wenn man (emotional) eher zur mysql-fraktion gehört.
just my 2 cents, joe

Gast · Montag 31. Oktober 2005, 19:24

Danke Joe!

Ist genau jene Art von Antwort, auf die ich hoffte!
Ich versuche, eben solche Aspekte zu sammeln.

Gruß!
Hawelka

gerold · Montag 31. Oktober 2005, 22:25

Anonymous hat geschrieben:
Hawelka hat geschrieben:und PostgreSQL festgelegt hab.
Ganz allgemeine bemerkung: das wäre das letzte was ich täte.

Hi!

PostgreSQL ist eine wunderbare Datenbank für Datenbankprogrammierer. Man kann dieses Ding so richtig ausreizen, wenn man Trigger, Prozeduren, Views, Referenzen zwischen den Tabelle, usw. einsetzt.

Das hilft unter anderem auch, Fehler von verschiedenen Backends zu vermeiden bzw. zu reduzieren oder Datenleichen zu vermeiden.

Das sind alles nur Vorteile von PostgreSQL, die du in dem Moment im weiten Bogen wegschmeißen würdest, wenn du datenbankunabhängig programmierst.

Datenbankunabhängig heißt meistens, den kleinsten gemeinsamen Nenner zu finden und nur bis zu dieser Grenze zu verwenden.

Eine Warenwirtschaft oder ein ERP-System braucht, meiner Meinung nach, ein gutes Backend. Verzichte nicht darauf, nur um datenbankunabhängig zu werden.

mfg
Gerold

gerold · Montag 31. Oktober 2005, 22:52

Hawelka hat geschrieben: - Webserver-Kommunikation
Von "lighttpd/fastcgi/WSGI" über "CherryPython/web-server" bis hin zu "zope" findet man eine Menge Möglichkeiten
Wichtig ist mir bloß, daß es einen Applikation-Server gibt, der einen HTTP-Request entgegennimmt, ohne daß er erneut die DB connecten muß.

Hi Hawelka!

Ich kann es dir nicht empfehlen, da ich noch keine PostgreSQL-Anwendung mit Zope programmiert habe. Theoretisch sollte es aber kein Problem sein.

Zope kann über einen Datebankadapter (DA) mit PostgreSQL verbunden werden. Diese Verbindung bleibt bestehen. Es muss sich also nicht ständig neu zur Datenbank verbinden.

Datenbankabfragen, die so gut wie immer die gleichen Daten zurück liefern, können sogar gecached werden. Eine Datenbankabfrage kann so eingestellt werden, dass diese z.B. nur jede halbe Stunde erneut ausgeführt. In der Zwischenzeit werden die gecachten Daten für die Rückgabe verwendet.

Zope läuft standardmäßig auch als HTTP-XMLRPC-Dienst. Das bedeutet für dich, dass du Zope auch als Middleware verwenden kannst. Einfache Frontends oder kleine Tools können von anderen Computern aus deine Anwendung ansprechen, Daten übergeben oder abrufen.

Wenn ich dich zu Zope als Application-Server überreden konnte, dann empfehle ich dir für diese Anwendung schon Zope3 zu verwenden. Zope3 glänzt mit neuem Design, und das nicht nur optisch

mfg
Gerold

gerold · Dienstag 1. November 2005, 08:34

gerold hat geschrieben:Zope3 glänzt mit neuem Design, und das nicht nur optisch

http://www.benjiyork.com/quick_start/

mfg
Gerold

gerold · Dienstag 1. November 2005, 08:50

Noch ein interessante Link dazu:

http://codespeak.net/z3/sqlos/

mfg
Gerold

Gast · Mittwoch 2. November 2005, 08:45

Hi Gerold!

gerold hat geschrieben: PostgreSQL ist eine wunderbare Datenbank für Datenbankprogrammierer. Man kann dieses Ding so richtig ausreizen, wenn man Trigger, Prozeduren, Views, Referenzen zwischen den Tabelle, usw. einsetzt.

Das hilft unter anderem auch, Fehler von verschiedenen Backends zu vermeiden bzw. zu reduzieren oder Datenleichen zu vermeiden.

Vor allem Trigger wären mir schon sehr wichtig.
Ich bin es gewöhnt, Trigger zum Erhalt der referentiellen Integrität zu verwenden. Einmal einen "Delete-Trigger" geschrieben, und sich nie wieder Gedanken machen, wer wo wann einen solchen Record löschen wird.

Das sind alles nur Vorteile von PostgreSQL, die du in dem Moment im weiten Bogen webschmeißen würdest, wenn du datenbankunabhängig Programmierst.

Datenbankunabhängig heißt meistens, den kleinsten gemeinsamen Nenner zu finden und nur bis zu dieser Grenze zu verwenden.

Eine Warenwirtschaft oder ein ERP-System braucht, meiner Meinung nach, ein gutes Backend. Verzichte nicht darauf, nur um datenbankunabhängig zu werden.

Verstehe!
Hinsichtlich DB-Unabhängigkeit, wäre mir ja in erster Linie wichtig, daß sich jemand mit einer externen Anwendung mit der DB connecten könnte (z.Bsp. zur Übernahme der Bestandsdaten in ein Spreadsheet etc.). Das sollte aber via ODBC oder JDBC auch bei PostgreSQL möglich sein.

LG!
Erich

Gast · Mittwoch 2. November 2005, 09:08

Hi Gerold!

gerold hat geschrieben: Zope kann über einen Datebankadapter (DA) mit PostgreSQL verbunden werden. Diese Verbindung bleibt bestehen. Es muss sich also nicht ständig neu zur Datenbank verbinden.

Was mir hier geistig noch fehlt, wäre der entsprechende Application-Server. Oder ist Zope genau dieses?

Was ich damit konkret meine ist:
Ein Server (z.Bsp. Apache mit FastCGI-Handler) lauscht auf Requests, deren URL sich auf ein Python-Script bezieht. Dieser Server weiß zunächst daß 10 (oder 100) Anwendungsprozesse (Python-Interpreter-Prozesse) darauf warten die Requestdaten entgegenzunehmen. Der Server weiß aber auch, welcher dieser 10 Anwendungsprozesse berade beschäftigt ist und übergibt die Daten einem der freien Prozesse.
Im Notfall wird ein 11. Prozess gestartet oder aber gewartet bis wieder einer frei ist.
Wesentlich dabei ist aber, daß diese 10 Anwendungsprozesse so agieren, daß sie nur beim erstmaligen Start sich mit dem DB-Server verbinden und daß nach Abarbeitung eines Requests die Prozesse wieder in Warteposition gehen.

Datenbankabfragen, die so gut wie immer die gleichen Daten zurück liefern, können sogar gecached werden. Eine Datenbankabfrage kann so eingestellt werden, dass diese z.B. nur jede halbe Stunde erneut ausgeführt. In der Zwischenzeit werden die gecachten Daten für die Rückgabe verwendet.

Ich denke, daß dieses Feature eher für Internet-Anwendungen mit riesen Datenbeständen geeignet ist.
Bei einem Intranet-Warenwirtschaftssystem möchte man aber immer genau das Gegenteil. Jeder Bestand der verändert wurde, soll sofort wirksam und sichtbar sein. Jeder Lagerbucheintrag soll sofort merkbar sein. Jede Artikeländerung ....

Zope läuft standardmäßig auch als HTTP-XMLRPC-Dienst. Das bedeutet für dich, dass du Zope auch als Middleware verwenden kannst. Einfache Frontends oder kleine Tools können von anderen Computern aus deine Anwendung ansprechen, Daten übergeben oder abrufen.

Das klingt "fetzig"

Wenn ich dich zu Zope als Application-Server überreden konnte, dann empfehle ich dir für diese Anwendung schon Zope3 zu verwenden. Zope3 glänzt mit neuem Design, und das nicht nur optisch

Ich werde mir Teile der Zope-Doku nochmals reinziehen.
Bis jetzt war ich lediglich begeistert vom Umfang und den Möglichkeiten. Richtig begriffen, was Zope eigentlich im Kern ist, hab ich noch nicht

LG!
Erich

raist1314 · Mittwoch 2. November 2005, 09:30

Hi...

also PostgreSQL als Datenbank ist ja schon mal erste Wahl, das kann ich Dir nur bestätigen. Ich habe einige recht grosse Projekte mit PostgreSQL als Datenbank realisiert(bis 2,5 Terabyte Daten) und bisher noch nie Probleme gehabt.

Als Application Server oder wie auch immer Du das nennen willst, kann ich Dir CherryPy empfehlen, das ist wirklich das genialste Toolkit für solche Sachen. Von mod_python kann ich Dir aus persönlicher Erfahrung nur abraten, ich hab damit eher schlechte Erfahrung gemacht. Nochmal zu CherryPy, ich hab damit für mehrere Kunden die verschiedensten Systeme gebaut und nie Probleme gehabt, zumal du in Verbindung mit dem Apache wirklich coole Sachen machen kannst...

Hast Du auch vor einen grafischen Client zu entwickeln? Wenn ja, wirf mal nen Blick auf Qt, die Jungs von Trolltech haben echt Ahnung davon was sie tun.

Gruss

Sebastian

gerold · Mittwoch 2. November 2005, 09:32

Hi Erich!

Anonymous hat geschrieben:Was mir hier geistig noch fehlt, wäre der entsprechende Application-Server. Oder ist Zope genau dieses?

Zope ist ein richtiger Web-Applicationserver und hält mehrere Threads bereit. Die Anzahl der gleichzeitig geöffneten Threads lässt sich in der Konfigurationsdatei einstellen. Alle Threads verwenden die gleiche Datenbankverbindung.

Anonymous hat geschrieben:Bis jetzt war ich lediglich begeistert vom Umfang und den Möglichkeiten. Richtig begriffen, was Zope eigentlich im Kern ist, hab ich noch nicht

Pflichtlektüre zu Zope: http://www.dzug.org/Members/vbachs/zboo ... /file_view

Man begreift Zope ziemlich schnell, wenn man das Tutorial durcharbeitet. Das hat man, je nach Konzentration, in einer oder wenigen Stunden durch. Danach versteht man ein wenig, wie die Vorlagensprache funktioniert und die Art, wie Zope auf Datenbanken zugreift. Auch wenn im Tutorial nur auf eine kleine, eingebaute Datenbank zugegriffen wird.

Zum Durcharbeiten dieses Tutorials empfehle ich dir, einfach mal Zope 2.8.4 zu installieren. Du findest unter http://gerold.bcom.at/zope_plone/zope_a ... en_windows eine Anleitung von mir, wie man Zope unter Windows installiert. Diese ist zwar noch für Zope 2.7.4 aber das lässt sich 1 zu 1 auf Zope 2.8.4 umlegen. Dort findest du auch Hinweise auf das Tutorial.

mfg
Gerold

Gast · Mittwoch 2. November 2005, 12:36

Hi Sebastian!

raist1314 hat geschrieben: Ich habe einige recht grosse Projekte mit PostgreSQL als Datenbank realisiert(bis 2,5 Terabyte Daten) und bisher noch nie Probleme gehabt.

seit wann zählt das Einwohnermeldeamt der Volksrepublik China zu deinen Kunden?

Als Application Server oder wie auch immer Du das nennen willst, kann ich Dir CherryPy empfehlen, das ist wirklich das genialste Toolkit für solche Sachen.

In der Tat. Hab ich beim ersten durchschmökern übersehen.
Da steht etwas von "ThreadPool"

The threadPool option determines how many threads CherryPy starts to serve requests.

Hast Du auch vor einen grafischen Client zu entwickeln? Wenn ja, wirf mal nen Blick auf Qt, die Jungs von Trolltech haben echt Ahnung davon was sie tun.

Ich denke ich hab mit der Web-Version schon genug am Hals

Zumal ich den Ansatz des "Thin Clients" recht gut finde.
Ein Stück Browser am PC und schon kanns losgehen ...

LG!
Erich

Gast · Mittwoch 2. November 2005, 13:03

Hi Gerold!

gerold hat geschrieben: Zope ist ein richtiger Web-Applicationserver und hält mehrere Threads bereit. Die Anzahl der gleichzeitig geöffneten Threads lässt sich in der Konfigurationsdatei einstellen. Alle Threads verwenden die gleiche Datenbankverbindung.

Das klingt einschlägig!

Pflichtlektüre zu Zope: http://www.dzug.org/Members/vbachs/zboo ... /file_view

Wow - das Teil hat 436 Seiten.
Eigentlich wollte ich am Wochenende mein Aquarium umgestalten

Zum Durcharbeiten dieses Tutorials empfehle ich dir, einfach mal Zope 2.8.4 zu installieren. Du findest unter http://gerold.bcom.at/zope_plone/zope_a ... en_windows eine Anleitung von mir, wie man Zope unter Windows installiert. Diese ist zwar noch für Zope 2.7.4 aber das lässt sich 1 zu 1 auf Zope 2.8.4 umlegen. Dort findest du auch Hinweise auf das Tutorial.

Ich hab leider (oder Gott sei Dank) nur Linux am rennen.
Aber die Installation wird das kleinste Problem sein.

Vielen Dank für Deine Infos!

LG!
Erich

Joghurt · Mittwoch 2. November 2005, 15:10

Anonymous hat geschrieben:
Pflichtlektüre zu Zope: http://www.dzug.org/Members/vbachs/zboo ... /file_view
Wow - das Teil hat 436 Seiten.
Eigentlich wollte ich am Wochenende mein Aquarium umgestalten

Also Zope ist definitiv nichts, was man mal so eben schnell nebenbei lernt.

Gast · Mittwoch 2. November 2005, 18:07

Joghurt hat geschrieben:Also Zope ist definitiv nichts, was man mal so eben schnell nebenbei lernt.

Ähmmm, und wer hat das behauptet?

gerold · Mittwoch 2. November 2005, 18:20

Anonymous hat geschrieben:
Joghurt hat geschrieben:Also Zope ist definitiv nichts, was man mal so eben schnell nebenbei lernt.
Ähmmm, und wer hat das behauptet?

Hi!
Ich glaube, er spielt da auf die Aussage "Eigentlich wollte ich am Wochenende mein Aquarium umgestalten" an.

mfg
Gerold

Gast · Donnerstag 3. November 2005, 19:53

Hi Gerold!

Ich weiß, aber diese Aussage hatte ungefähr so viel Qualität wie: "Umso heißer desto Autsch!"

LG!
Erich

mitsuhiko · Donnerstag 3. November 2005, 20:35

Hawelka hat geschrieben:- Webserver-Kommunikation
Von "lighttpd/fastcgi/WSGI" über "CherryPython/web-server" bis hin zu "zope" findet man eine Menge Möglichkeiten
Wichtig ist mir bloß, daß es einen Applikation-Server gibt, der einen HTTP-Request entgegennimmt, ohne daß er erneut die DB connecten muß.

ich weiß, ich wiederhole mich, aber WSGI deckt deine Bereiche ab, da es auf FastCGI, SCGI und mod_python sowie noch anderen läuft, die im Speicher bleiben. Du kannst dann eine persistente Verbindung aufbauen, die erst beim schließen des Threads geschlossen wird.