Hallo, >> ??? Wen interessiert das? Das ist unsichtbare Technik, kein Mensch, der >> den Unterschied zwischen Frontend und DMBS kennt, kann das ernsthaft zum >> Kriterium einer Modellanwendung machen.
Die Zielgruppe von OO! Dies soll eine Beispielanwendung sein; mit Platz für eigene Erweiterungen/Ideen.
Jetzt mal im Ernst: Wenn Ihr das professionell aufsetzen wollt, dann ist OO kein Weg nach der reinen Lehre. Wo bleiben die einzelnen Zugriffsschichten? ORM, bussiness-logic, multi-tier? etc.pp. Folglich kann OO nur die Rolle eines simplen reporttool spielen.
Eine Beispieldatenbank hat den Sinn - mit Bordmitteln - die Möglichkeiten aufzuzeigen. Sie soll ohne externen Datenbankserver auskommen. Es gibt eine Menge BenutzerInnen, die sich auf eine bestimmte Datenbank spezialisiert haben und all diese Fälle kann keiner abbilden. Wer will, kann dann ein SQL-Skriptum für - was auch immer - DBMS bereitstellen und alle sind glücklich.
Mein Vorschlag: Start mit der Entwicklung mit dem Aufbau des Datenbankschema mit Hilfe UML, darauf folgend ein global gültiges ERM. Von diesem ERM können dann sämtliche Derivate der unterschiedlichen DBMS abgeleitet werden. Des weiteren: Aufteilung der Arbeit in verschiedene Gruppen.
- z.B. DB-Gruppe - z.B. Gruppe für das Formular-Frontend - z.B. für das Reporting - und Koordination / Qualitätssicherung.Für die Dokumentation ist jede Gruppe eigenverantwortlich und wird dann zusammengeführt.
Vorab solltet Ihr/wir die Zielsetzung und Voraussetzungen genau diskutieren und klarmachen, wer die Zielgruppe ist, und was diese möchte. Mutmaßungen bringen Euch/uns nicht weiter, genauso wenig wie spezielle Vorlieben einzelner Entwicklungsteilnehmer.
Mit freundlichen Grüßen Guido Volkmann
<<attachment: dialog.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
