BoOnOdY hat geschrieben:ich wollte mal spaßeshalber eine kleine Kundendatenbank mit HTML oberfläche und Python scripts und eventuell einer einbindung in zope gestalten.
Kunden anlegen
Aufträge zu Kunden anlegen
Rechungsausdruck mit vortlaufender Rechungsnummer und Kundenbezug
Hi Tim!
Von großen und kleinen Programmen
Bitte nimm es mir nicht krumm, aber jetzt komm zuerst mal eine riesige Portion Rechthaberei. Aber ich weiß nicht, wie ich das sonst so schreiben soll.
Du bist jetzt ganz am Anfang mit deiner Datenbankprogrammiererei. Deshalb mein gut gemeinter Tipp: Mache etwas kleines und plane **nicht** ein, das Programm später einmal mit mehr Power auszustatten. Kleine Adressdatenbank -- Ja. Aufträge und Rechnungen damit verwalten -- Nein.
Warum? Deine ersten paar Datenbankanwendungen, mit mehr als nur zwei oder drei Tabellen, brauchst du zum Testen der Möglichkeiten, zum Probieren und um dich in das System einzufühlen.
Ich habe noch niemanden getroffen, der seine zweite Datenbankanwendung auf die gleiche Art, wie seine erste Datenbankanwendung, schreiben würde. Es gibt da mehrere "Lehren". Die einen lassen der Datenbank mehr Macht und erstellen die Datenbank so, dass diese die eigentliche Hauptanwendung ist und sich um die Datenintegrität kümmert. Die anderen wollen so wenig Logik wie möglich an die Datenbank abgeben und schreiben eine umfangreiche Middleware. Die einen überlassen die Benutzerverwaltung und damit auch die Zugriffsverwaltung der Datenbank. Die anderen lassen die Middleware, die Zugriffsverwaltung übernehmen.
Alles hat seine Berechtigung. Nur du musst erst abschätzen lernen, was für deine Programme das Richtige ist. Und jetzt kommt das was ich eigentlich sagen wollte: Eine Kundendatenbank, mit der du auch Aufträge verwalten kannst, Rechnungen erstellen und ausdrucken kannst --> das ist keine kleine Datenbankanwendung die man spaßeshalber mal so nebenbei programmiert. Such dir ein überschaubares, kleines Beispiel. Definiere genau was damit gemacht werden kann. Und dann mach es. -- Aber bitte nicht mit dem Hintergedanken, aus dieser kleinen Anwendung später einmal etwas Großes machen zu wollen. Das geht nicht. Entweder du machst von Anfang an etwas Großes, mit allem was eine große Anwendung so braucht, oder du machst etwas Kleines.
Eine kleine Datenbankanwendung lässt sich recht schnell erstellen. Dabei lässt man die Dinge aber außer Acht, die für eine kleine Datenbankanwendung einfach nicht wichtig sind. Z.B. brauchst du dir bei einer kleinen Datenbankanwendung keine Gedanken darüber machen, wer von wo aus auf die Daten zugreifen darf. Du musst dir auch keine Gedanken über eine leichte Erweiterbarkeit deiner Anwendung zu machen. Du brauchst keine Programm-Mittelschicht, die die Logik deiner Anwendung für mehrere verschiedene Benutzeroberflächen (HTML, Kommandozeile, GUI,...) so aufbereitet, dass die Benutzeroberflächen sich nur um die Oberfläche kümmern müssen.
Es gibt natürlich noch mehr Dinge, die für eine zukünftig große, erweiterbare Anwendung zu berücksichtigen sind. Das alles fällt bei einer kleinen Anwendung weg. -- Aber nur dann, wenn man sich von vornherein Bewusst ist, dass es eine kleine, nicht erweiterbare Anwendung werden soll.
Hat man sich das vor Augen geführt, dann macht man sich keine Gedanken mehr über die verschiedensten Schichten eines Programmes, sondern programmiert in kürzester Zeit eine kleine Anwendung. Und erstaunlicherweise funktionieren diese kleinen Anwendungen meistens hervoragend.
Eine Anwendung, die als CGI-Programm laufen soll, dann evt. zusätzlich noch in Zope -- das ist zwar machbar, aber macht keinen Sinn. Außgenommen, es soll eine "große" Anwendung werden. Dann kannst du mehrere Programmschichten einplanen. Eine Datenschicht, eine Mittelschicht für die Programmlogik und mehrere verschiedene Benutzerschnittstellen.
Nehmen wir mal an, du erstellst dir zuerst eine CGI-Anwendung, mit der du Kundenadressen anlegen, suchen und anzeigen kannst. Du hast das ganze so programmiert, dass schon beim Eingeben einer Postleitzahl, alle möglichen Orte aus einer Liste ausgewählt werden können. Umgekehrt geht das natürlich auch -- Schreibt man einen Ort in ein Feld, dann werden alle möglichen Postleitzahlen dieses Ortes vorgeschlagen. Beim Anlegen einer Adresse prüfst du auch nach, ob es eine Person mit ähnlichen Daten und dem gleichen Geburtstag bereits gibt. Wenn Ja, dann fragst du den Benutzer, ob die Adresse trotzdem angelegt werden soll. Diese Anwendung läuft dann ohne Umwege mit einem Webserver wie z.B. dem Apache zusammen. Die Rückgabe dieses Programmes ist HTML-Code, den der Apache an einen Browser übermitteln kann.
Danach möchtest du diese Anwendung auch in Zope laufen lassen. Die Prüfungen, die du beim Anlegen einer neuen Adresse machst, die musst du jetzt noch einmal programmieren, da deine CGI-Anwendung ja HTML zurück gibt und nicht Daten, die du in Zope verwenden könntest. Jetzt stehtst du da und musst dich entscheiden.
- CGI-Anwendung so umprogrammieren, dass man einen Parameter übergeben kann der dem CGI-Programm mitteilt, die Daten nicht als HTML-String sondern in einer anderen Form zurück zu geben.
- Mittelschicht programmieren, die sich um die Logik kümmert, die dann vom CGI-Programm eingebunden wird. Diese Mittelschicht kann dann auch von Zope aus eingebunden werden.
- Zope als Mittelschicht verwenden. Zope greift auf die Datenbank zu und stellt Funktionen zur Manipulation der Daten und Suche zur Verfügung. Vorteile: Zope hat eine Benutzer- und Zugriffsverwaltung eingebaut und ist von Haus aus ein XMLRPC-Server. Alle deine Benutzerschnittstellen können dann per XMLRPC auf die Logikschicht (Zope) zugreifen und mit den Daten arbeiten. Allerdings gibt es dann keinen Grund mehr, eine Benutzerschicht als CGI laufen zu lassen, da Zope das um ein Vielfaches besser kann.
@All: Viel Tobak, ich weiß. Bitte nehmt es mir nicht übel. Aber wo soll ich sonst so meine Programmierer-Gedanken los werden, wenn nicht hier im Python-Forum
lg
Gerold
