Ernst Hügli schrieb: Hallo Ernst,
zunächst mal vorab: ich schätze es ausdrücklich, wenn jemand, wie Du es hier getan hast, mir gegenüber Tacheles redet. Erlaube mir bitte im Gegenzug einige Bemerkungen. Du wirst hier im Thread keine Aussagen vor mir finden, wo ich glauben machen möchte, ich habe keinen Respekt vor dem Aufsetzen einer Datenbank. Das Gegenteil ist der Fall. Mein Respekt war die ganzen letzten Jahre so groß, dass ich nicht mal erwogen habe, sowas anzugehen. Die unbefriedigenden Merkmale der Tabelle, mit der ich versucht habe, meinem Freund das Erfassen leichter/bzw. überhaupt möglich zu machen, in Verbindung mit dem Hinweis einiger hier "denk' mal über eine Datenbanklösung nach", ließen mich neugierig werden. Schlechter als mit der aktuellen Calc-Tabelle, dachte ich mir, könne es schon nicht werden. Meine erste Vorstellung war eine rudimentäre Datenbank, die nur aus einer einzigen Tabelle besteht und weder Formular noch Bericht aufweist. Einfach nur ein Container mit viel strikteren Regeln (Datentypen, Feldeigenschaften) als es eine Calc-Tabelle erlaubt. Als "Formular" sollte die Base-Tabelle selbst dienen. Als "Bericht" ein Import der Daten von Calc aus. Erstmal. Evolution wird schon möglich sein, so meine Überlegung. Dabei wollte ich keineswegs einen Schnellschuss. Ich war sogar hier derjenige, der "bremsend" Einfluss nahm, als mir schon Formulare vorgeschlagen wurden (was ich in keiner Weise kritisieren möchte, denn das war absolut nett und wohlwollend gemeint), wo ich noch einige Zeit über der Struktur brüten wollte. Zu Deinem Vorschlag, nach einer professionellen Software Ausschau zu halten oder in einer Community anzufragen: das werde ich auf jeden Fall erwägen, sobald ich aus eigener Erfahrung Deine Einschätzung bestätigen kann. Pfusch hat mich noch nie befriedigt. Angemessene Imperfektion sehr wohl. Ich bin nicht so vermessen zu denken, die selbstgebaute Anwendung eines blutigen Anfängers könne sich mit der Universalität, Bedienfreundlichkeit oder gar der Wohlgestalt einer Profi-Software messen. Ich schreibe das nicht nur als Floskel: Aufgeben ist definitiv eine Option. Meine Eitelkeit hält das aus. Wenn eine Lösung herauskäme, die ich vor meinem Freund nicht guten Gewissens vertreten kann, werde ich ihm raten, sich was Besseres zu suchen und dabei auch unterstützen. Du schreibst, ich würde ihm etwas vorgaukeln. Das war und ist nicht der Fall. Zu "Deine Bemerkungen haben mir gezeigt, dass Du das Wesen einer DB (noch) nicht begriffen": Ohne Frage habe ich das Wesen einer Datenbank noch nicht begriffen. Du machst dies jedoch IMHO an einem unpassenden Aufhänger fest. Bitte gehe auf die von mir genannten Argumente ein, wo ich schreibe, dass ich keinen guten Grund sehe, bewußt eine für menschliche Verwalter (ich schrieb explizit nicht von Anwendern) schlechter lesbare (Benennungen, Reihenfolge) und somit schlechter wartbare Struktur anzulegen. Ich hoffe ich konnte einiges aufklären. Da Du das Erstellen von DB unterrichtest: darf ich noch um einen Rat bitten? Welche didaktisch exzellente (deutschsprachige) Literatur zur Struktur (relationaler) DB kannst Du mir empfehlen? Schöne Grüße, Andreas > 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 -- OOo 3.1 http://borumat.de/openoffice-writer-tipps --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
