Hallo Andreas
Erlaube mir ein paar allgemeine Bemerkungen zu Deinem Anliegen. Du hast
zwei Probleme: zum einen will Dein Freund, der Komponist, ein Werkzeug,
das ihm erlaubt, seine Werke zu katalogisieren. Zum anderen willst Du DB
lernen.
Tut mir leid, aber als einer, der selber Berufsmittelschüler u.a. auch
in DB unterrichtet, muss ich Dir sagen: vergiss es, diese beiden
Probleme in einem Aufwaschen lösen zu wollen! Du wirst scheitern. Wenn
es so einfach wäre wie Du zu glauben scheinst, dann würden
professionelle DB-Entwickler woll kaum ein FH- oder Uni-Studium benötigen.
Um das Problem Deines Freundes zu lösen, gibt es drei Wege: ein
professionelles Programm, das kostet: scheidet aus, weil Dein Freund
nicht über die Mittel verfügt, wie Du schreibst. Dann bleiben immer noch
zwei andere Wege: suche gezielt im Open Source-, Freeware-Bereich, was
es schon an Lösungen gibt - ich bin immer wieder erstaunt, was es in
diesem Bereich alles gibt, und was erfahrene (!!) professionelle
Entwickler der Community bereit sind, der Allgemeinheit gratis oder
allenfalls gegen eine mehr als nur bescheidene Lizenzgebühr zur
Verfügung zu stellen. 30€ für eine solche Lizenzierung müsste auch
Deinem Freund die Professionalität wert sein. Sollte wider Erwarten auch
dieser Weg nicht zum Ziel führen so wäre die gezielte Anfrage in der
Community zu lancieren, ob jemand bereit ist, für ihn diese DB
professionell zu entwickeln - entweder als OS/FS-Produkt, oder aber
gratis für Deinen Freund, weil er sein Know-how auf User-Seite zur
Verfügung stellt. Aber lass als Anfänger die Finger davon, eine komplexe
DB für den professionellen Einsatz entwickeln zu wollen - Du wirst Dir
und Deinem Freund damit nur Frust und Scherereien einfahren, und ein
Produkt wird - wenn überhaupt - erst in mehreren Jahren einen
einigermassen befriedigenden Stand erreichen.
Dieses mein hartes Urteil hat sich gebildet, als Du wegen der Formulare
und der Reihenfolge der DB-Felder geschrieben hast. Deine Bemerkungen
haben mir gezeigt, dass Du das Wesen einer DB (noch) nicht begriffen
hast: die Struktur einer DB ist für den Endbenutzer absolut belanglos,
weil er sie in einer gut gemachten DB- *Applikation* gar nie zu sehen
bekommt. Was er sieht, sind Formulare und Berichte - und denen ist es
sch...-egal, wie die Felder heissen, in welcher Reihenfolge sie
aufgeführt sind, ja sogar, in welcher Tabelle sie untergebracht sind.
das ist nur eine Frage der Fähigkeiten des DB-Entwicklers: er kann ihnen
neue Namen geben (bzw. für den User sichtbar: er kann sie irgendwie
beschriften), er kann sie anordnen, wie ihm beliebt, und er kann sie aus
allen möglichen Tabellen mixen - sogar aus Abfragen, dh. aus Tabellen,
die erst zur Laufzeit aufgebaut werden. Ich habe mit meinen Schülern vor
gut zwei Monaten eine einfache Termin-DB entwickelt: selbst dieses
einfache Beispiel führt mit Tabellen und Abfragen schnell dazu, dass man
ein Dutzend oder mehr Tabellen hat, wenn man sie gut strukturiert und
auf referenzielle Integrität sowie die Relationen nicht verzichten will.
*Kein* User hat in dieser komplexen Situation noch den Überblick, was
wofür gedacht ist - hier *muss* ich als DB-Entwickler mit Formularen und
Berichten ein vereinfachtes User-Interface dazwischen schalten. Das sind
aber nur die Basics der ganzen Entwicklung. Solange Du das nicht
begriffen hast, hilfst Du Deinem Freund nicht, wenn Du ihm vorgaukelst,
Du könntest ihm auf die schnelle eine absolut narrensichere (!),
userfreundliche (!), all seine Bedürfnisse befriedigende Lösung entwickeln.
Trotzdem einen schönen, sonnigen Sonntag.
Freundlich grüsst
Ernst Hügli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org
For additional commands, e-mail: users-h...@de.openoffice.org
