Hallo Liste, besonders alle Teilnehmer dieses Threads,
das Thema ist interessant.
Ein solches Projekt sollte mit einem Beispiel begonnen werden, das
möglichst viele Anwender kennen.
Ich plädiere deshalb für eine Vereins-Datenbank.
Millionen Deutsche sind Vereinsmitglieder, entsprechend viele darin
Funktionsträger.
Es gibt unglaublich viele Arten von Vereinen, auch OOo ist in Bereichen
einer.
Alle angesprochenen Aufgaben sind auch bei einem Verein nötig, auch ein
Terminkalender.
Darüber hinaus alles bis hin zu einer Buchhaltung.
Vor allem aber ist ein gut strukturiertes Mitglieder-Tabellenwerk
Voraussetzung, mit dem man gut die Regeln der Normalisierung der Daten
vermitteln kann.
Man denke nur an Turniere bei Sportvereinen oder Auftritte bei Chören,
jegliche Veranstaltungen bei anderen Vereinen, seien es Kurse bei einem
gemeinnützigen Verein zur Förderung Behinderter oder auch Hochbegabter
oder das Jazzfestival eines Clubs von Jazzfreunden.
Da gibt es nämlich Mitglieder und Teilnehmer an den Veranstaltungen, die
eine m:n-Beziehung erforderlich machen und die man an solchen einfachen
Beispielen gut herleiten und darstellen kan.
Diese Bedürfnisse sind für die größte Anzahl potentieller Interessenten
und damit Adressaten eines solchen Projekts einsichtig.
Außerdem gibt es freie Beispiele dafür auch in Access, an denen man
etwas abgucken kann. Auch beim Umsetzen lernt man.
Und da gebe ich Andreas Saeger und Andreas Scherbaum absolut recht,
-ohne eine gründliche Ermittlung der benötigten Daten und eine der
Normalisierung dieser Daten, also eine sinnvolle Aufteilung in Tabellen
geht gar nichts.
Wer schon mal mehr mit Datenbanken gemacht hat weiß, daß die Hauptarbeit
in der sinnvollen Gestaltung der Tabellen liegt. Das ist insbesondere
von essentieller Bedeutung für die Geschwindigkeit der Abläufe in der
Datenbank und die Einfachheit der Zugriffe durch Abfragen.
Ein erfahrener Datenbankdesigner sitzt erst mal stundenlang (wenn nicht
mehr) mit dem Bleistift vor einem großen Blatt Papier und macht eine
Stoffsammlung hinsichtlich der wirklich benötigten Daten. Sodann
überlegt er, welche Auswertungen er braucht und welche Eingabemasken
sinnvoll sind.
Diese werden über Abfragen mit Daten bedient, also müssen die Abfragen
sorgfältig geplant sein und man fragt sich bei jedem Schritt, ob die
Tabellenstruktur wirklich so wie bisher gedacht sinnvoll ist.
Wenn man hier konsequent vorgeht, dann kann man wirklich - wie Andreas
Saeger schreibt, mit nur ganz wenigen "Makros" auskommen. Und das sollte
das absolute Ziel sein. man will ja den Umgang mit base vermitteln und
nicht dessen Programmierung.
Und das geht tatsächlich, ich mache meine Buchhaltung einer
Anwaltskanzlei seit 1996 mit Access und die einzige Funktion ist das
sofortige Öffnen der Listen- und Kombofelder beim Focuserhalt.
Alles andere sind SQL-Verarbeitungsanweisungen in den Abfragen.
Mit Wenn-Klauseln generiere ich aus den Bruttobeträgen sowohl den
Nettobetrag als auch die MwSt.
Ein gruppierter Bericht macht eine perfekte BWA, Summen und Salden,
Einnahme- Überschußrechnung, Umsatzsteuer-Anmeldung, alles was man will!
An Andreas Saeger: Deine Darstellungen finde ich gut, analytisch und
systematisch strukturiert.
Deinen Frust kann ich aus Deinen Schilderungen nachvollziehen, denn Du
vermittelst intensive Erfahrungen und Engagement.
Ich würde mir wünschen, daß Du diese in das Projekt auch in der Weise
einbringst, daß Du sagen kannst, welche Funktionen bei base gegenüber
dem häufig genannten Access nicht möglich sind.
Das wäre sehr wertvoll, denn dann kann sich eine große Vielzahl von
Interessenten langes Suchen und Probieren sparen und sie würden Frust
vermeiden.
Ich jedenfalls habe schon oft nach solch einer Liste gesucht und vieles
wäre einfacher gewesen, hätte ich nicht versucht, eine nicht mögliche
Funktionalität doch noch hinzukriegen.
Das sollte jedenfalls ein Element des Projektes sein.
Gerade darüber kann man bei Abfragen sowohl den Entwurfsmodus als auch
die direkte SQL- Eingabe lernen und eben auch deren Grenzen.
So habe ich gelernt, daß das Beispiel von Andreas vom 04.02.,
<WHERE "Name" LIKE :Beginnt || '%' in meiner Umgebung nicht
funktioniert, nämlich OOo 3.1 auf Fedora 11 mit einer MySQL-datenbank
auf dem Server (Fedora 4) im Netz.
Offensichtlich ist das ein Beispiel aus der HSQL-Umgebung, denn MySQL
gibt im Handbuch dazu an, LIKE CONCAT( :Name, '%') zu benutzen.
Das funktioniert auch aus dem SQL-Fenster in base heraus, geht man aber
in den Entwurfs-Assistenten, kommt eine Fehlermeldung.
Das ist ja auch alles nicht schlimm, wenn man darum weiß.
Ganz wichtig: Wie soll das Projekt organisiert werden? Hier auf der
Liste ist eine gemeinsame Entwicklung kaum sinnvoll möglich.
Wer nimmt was in die Hand?
Es sollte eine BASE- Demonstration sein und nicht irgendwas auf der
Basis von Writer.
Und es ist sicherlich sinnvoll, ganz neu von vorn anzufangen und nicht
irgendein steckengebliebenes Projekt aufzuarbeiten und dann in eine neue
Richtung zu pressen.
In der Hoffnung auf eine produktive Diskussion ohne philposophische
Abhandlungen oder pädagogische Theorien grüßt
Manfred
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org
For additional commands, e-mail: users-h...@de.openoffice.org
