[de-users] Re: Datenbank-Beispiel für Base
Ernst Hügli wrote: Hallo Michael Am 16.02.2010 11:03, schrieb michael: Auch hier hilft nur detailliertes Wissen über die Bedingungen der Praxis. Tut mir leid, wenn ich jetzt sehr hart auf Deine Mail antworte. Aber mir scheint, von ein paar wenigen Ausnahmen abgesehen, sind die Datenbankexperten hier vor allem eins: grosse Schwätzer, aber k(l)eine Macher. Ihr wisst alle ganz genau, warum etwas nicht geht. Aber einen Ja, genau. Da kann ich Dir *eigentlich* nur zustimmen, muss aber hinzufügen, dass Du dennoch falsch gewickelt bist. Das Problem ist nicht so sehr, dass dieses oder jenes nicht gemacht werden könnte oder schon gemacht wurde, sondern dass Base in dem Moment zu einer _Entwicklungsplattform_ wird, wo Du eine Datenbank mit Eingabeformularen erstellst. Du benutzt dass Programm, um etwas zu erzeugen, das später von einem angenommenen Benutzer benutzt werden soll. Auf user.services.openoffice.org kann man Beispieldatenbanken heraufladen, und ich tue dies ausdauernd mehrmals pro Woche. Dies hilft nur einer Minderheit von Fragestellern weiter. Zum einen weil ein Teil der Fragesteller nicht in der Lage ist, angebotene Lösungswege auf das eigene Problem zu übertragen, zum anderen weil die Leute von der einen oder anderen Datenbank derart verwöhnt sind, dass sie es partout nicht akzeptieren können, wenn gewisse Selbstverständlichkeiten in Base etwas umständlicher darstellbar sind (gerade weil die Entwicklungsplattform einfacher gestrickt ist, ist vieles schwieriger). Fast jede Beispieldatenbank, selbst die ganz einfach gestrickten, übersteigen ab einem sehr frühen Punkt die Fähigkeiten der angebotenen Assistenten (Wizards), so dass schon bei ganz gewöhnlichen Standardaufgaben die Kommandozeile (ExtrasSQL...), die direkte Abfrage von der Datenbank (SQL-Editor) und manuelles Formulardesign zum Einsatz kommt. Zu Makros nur soviel, da ich sonst völlig abschweife: Der exzessive Einsatz von Makros verdeutlicht mehr Probleme als er zu lösen in der Lage ist. Das Verständnisproblem potenziert sich sich dadurch. Oft entsteht der Eindruck, dass man programmieren muss, um überhaupt eine brauchbare Datenbank zu bekommen. Auch auf die Gefahr hin, dass ich jetzt selber falsch gewickelt bin: Ich behaupte, dass es mit dem gegebenen Wekzeugsatz irrational ist, ein Datenbankprodukt zu erstellen, für das andere Leute gerne Geld auf den Tisch legen würden. Die erste Frage wäre: Wo kann ich das an meine Bedürftnisse anpassen? Antwort: Installiere einen Datenbankserver deiner Wahl, implementiere die erforderlichen Strukturen, Views, stored Procedures, Trigger und Zugangsberechtigungen, wenn Deine Datenbank dann fertig ist, programmiere schließlich ein Frontend hinter die archaische Formularstruktur von OOo Base. Ach so, danke. Ich dachte Base wäre ein Datenbankprogramm. Nein, ist es nicht wirklich. - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Datenbank-Beispiel für Base
Am Dienstag 16 Februar 2010 13:30:01 schrieb Ernst Hügli: schnipp (Roman gekürzt) Also: warum nicht losgehen, einige der von Robert, von Mechtilde, oder von anderen hier vorgeschlagenen oder bereitgestellten Beispiele nehmen, und so weiter entwickeln, dass es für ein Greenhorn möglich ist, in die Geheimnisse von DB's einzutauchen. Bist Du, Andreas, seid Ihr anderen DB-Experten dazu bereit, oder wollen wir statt dessen lieber weiter über die Grenzen und Beschränktheiten von Base meditieren und unseren Frust loswerden? ich will Dir mal erklären, was ein User macht, der sich für sich erstmalig eine Datenbank entwickeln will: Er kauft sich ein Buch, und sei es über Access, und macht sich grundsätzlich mit Datenbanken vertraut. Wenn er die Materie begriffen hat, fängt er an, sich eine Datenbankanwendung zu basteln. Im beruflichen Bereich bekommt er zu 99,9% Datenbanken gestellt und wird darin eingearbeitet. Gruß Thomas Mit wieder etwas mehr Hoffnung grüsst Ernst - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank-Beispiel für Base
Ernst Hügli wrote: Hallo Andreas Am 16.02.2010 12:40, schrieb Andreas Saeger: Ich behaupte, dass es mit dem gegebenen Wekzeugsatz irrational ist, ein Datenbankprodukt zu erstellen, für das andere Leute gerne Geld auf den Tisch legen würden. Die erste Frage wäre: Wo kann ich das an meine Bedürftnisse anpassen? Antwort: Installiere einen Datenbankserver deiner Wahl, implementiere die erforderlichen Strukturen, Views, stored Procedures, Trigger und Zugangsberechtigungen, wenn Deine Datenbank dann fertig ist, programmiere schließlich ein Frontend hinter die archaische Formularstruktur von OOo Base. Ach so, danke. Ich dachte Base wäre ein Datenbankprogramm. Nein, ist es nicht wirklich. Einmal mehr: Du machst nieder, Du zeigst, was alles nicht geht - aber wo ist Dein Ansatz einer Lösung? Jammern kann jeder, aber das löst keine Probleme. Vor allem: Du sprichst schon wieder von einem Luxusschloss - kein Architekt, kein Baumeister wird so anfangen. Es gibt wirklich sehr, sehr viele Datenbankentwickler für die es ungemein attraktiv *wäre*, ihre fertige Desktop-Datenbank von Access, FileMaker oder ähnlichem nach OOo zu portieren, ganz einfach wegen der Plattformunabhängigkeit und Lizenzkostenfreiheit der zugrundeliegenden Software. Ich behaupte nicht, Du habest Unrecht - aber wenn es so ist: könnte nicht gerade das *ein* Lernziel sein? Und den Lernenden dadurch aufzeigen, welche Alternativen sie haben? *Was* sie mit Base lösen können, wo die Grenzen sind, und wo sie nach Alternativen (Programmieren *oder* einen anderen DB-Server aufschalten) suchen müssen bzw. wann sie einen Experten einschalten müssen. Gerade in dem Falle kann es nützlich sein, wenn im Gespräch mit dem Experten der User über ein Grundverständnis für DB's verfügt - das Gespräch wird in jedem Falle fruchtbarer. Gibt es in rauhen Mengen. Scheint aber nicht zu helfen wenn Point-And-Click die einzig bekannte Methode ist, einem Computer etwas zu entlocken. Sinngemäß zitiert: Ich habe keinen Bock auf einen akademischen Kurs in Datenbankphilosophie sondern ich will wissen, wie ich an's Ziel komme! als Gegenantwort auf eine recht simple Antwort wie eine Datenbank mittels Primärschlüsseln editierbar gemacht werden kann, falls das die Datenbankverbindung überhaupt hergibt. Ich behaupte aber, die wenigsten werden so weit in Base und DB's eindringen, dass die Beschränkungen für sie zum Problem werden. Denen aufzuzeigen, wo ihre Grenzen sind, könnte ja auch ein Lernziel sein. Gerade, damit nicht die Haltung aufkommt: Ich brauche nur das richtige Programm, dann kann ich *alle* Probleme selber lösen. *Das* ist aber kein Base-spezifisches Problem. Was glaubst Du, wieviele Leute meinen, bloss weil sie ein bisschen in Writer tippen können seien sie die geborenen Layouter und Buchdrucker. Und verstossen gegen soviele Regeln wie nur möglich. Bloss: Writer ist etwas geduldiger und grosszügiger gegen Fehlmanipulationen bzw. typische Fehler als Base. Und genau das kann mit einer Entwicklungsumgebung nicht mehr funktionieren, obwohl MS Access hier ähnliche Maßstäbe setzt wie Word/Excel (Access macht das für mich). Damals(tm), als ich das gleiche Drama mit MS Access durchlitt, hat mir erst ein wenig nackte Theorie das Aha-Erlebnis gebracht. Von da an habe ich überhaupt begriffen, was das Tool von mir verlangt bevor es in die Lage versetzt ist, mir zu helfen. Die Base-Komponente und ihre zahlreichen Fehler sind ein viel größeres Problem als die Beschränkungen. Die ganze Anwendung ist faulig. Man kann wesentlich mehr erreichen, als die grafische Oberfläche nahelegt. Leider beinhaltet wesentlich mehr auch ein paar triviale Selbstverständlichkeiten, für die man bereits zum Texteditor greifen muss. Die Art und Weise wie der grafische Abfragedesigner durch immer andere Fehler funktionierende Abfragen in kaputte verwandelt hat schon etwas unterhaltsameres. Dabei beherrscht der ganze Abfragedesigner nicht mehr SQL als ein blutiger Anfänger nach einem halbtägigen Einführungskurs selber beherrschen könnte, was es andereseits recht leicht macht, das Ding komplett zu ignorieren. Von daher: Aber na klar, Du stößt schon gleich am Anfang and die Grenzen von Base. Macht aber nix, wenn Du Dich auf die _einfachen_Grundlagen_der_Beschreibungssprache_SQL_ einlassen kannst. Der Formularassistent kann wesentliche Aspekte einer ganz einfachen Relation zwischen zwei Tabellen nicht abbilden, weil er keine Listenfelder drauf hat. Dabei kann man im Handbetrieb fast alle denkbaren Relationen über viele Tabellen hinweg in brauchbare Formulare gießen (dazu sollte man dann aber besser die Assistenten für Steuerelemente abschalten!). Der Anfänger will aber zuallererst sein Formular erstellen, sieht aber nur den extrem limitierten Assistenten oder ein aber leeres Writer-Dokkument, bei dem die wichtigste Werkzeugpalette auch noch konsequent ausgeblendet wird: die Symbolleiste Formulardesign. All dies und die Tatsache, dass
[de-users] Re: Datenbank-Beispiel für Base
Mechtilde wrote: Soweit ich das noch in Erinnerung habe ist das eine ganz einfache Version, die sowas wie ein Waren-/Kunden-System abbildet. Hallo, Nordwind.mdb ist für mich so eine Art Leistungsschau für MS Access. Sie enthält so gut wie gar keine Makros und liefert mannigfaltige, sehr lehrreiche Beispiele wie Relationen erst in einer Datenbank definiert und dann in Formularen zugänglich gemacht werden können (Editieren über Tabellengrenzen hinweg). Sicher kann man mit vielfachem Zeitaufwand, wesenlich mehr Makro-Code und Handarbeit auch in Base eine Nordwind.odb erstellen. Dennoch schätze ich mal, dass Base in so einem Vergleich immer schlecht dasteht. Base und Access sind einfach nicht wirklich miteinander vergleichbar. In Base ist alles auf Officedokumente orientiert. Der Kern aus OOo 1.x setzte immer eine bereits vorhandene relationale Datenbank voraus, aus welcher Datensätze in Dokumente importiert werden sollen. Daran hat sich bis heute nur sehr wenig geändert. Hast Du eine funktionierende Serverdatenbank, dann liefert Base eine hervorragende Datenquelle für Officedokumente und der SRB fügt den nötigen Schuss Professionalität und Blendwerk hinzu. Die Werkzeuge, die in Version 2.x hinzugekommen sind, um eine Datenbank aus dem Nichts zu erzeugen sind allerdings bis heute derart fehlerhaft, unvollständig und unglaublich irreführend fehlimplementiert, dass meiner Meinung nach ein Einstieg in die Welt der Relationalen Datenbank über Base/HSQLDB praktisch unmöglich ist. Was sinvolle Beispieldatenbanken angeht, so findet man mannigfaltige Inspirationen im Calc-Support. Sobald die Leute Word/Writer beiseite legen, suchen sie geradezu verzweifelt nach einer Möglichkeit, ihre Daten zu organisieren und stolpern umgehend in die Tabellenkalkulation, wo sie Papiertabellen in die 67 Millionen Quadratzellen große Spielmatrix übertragen ohne die (doch recht komplizierten) Spielregeln dieser Matrix auch nur im Ansatz zu kennen (auch Calc/Excel unterscheiden Datentypen und können mit normalisierten Tabellenbereichen mehr anfangen als mit freihändigen Datensammlungen über hunderte Sheets und Dateien). - Arbeitszeiteiterfassung im Schichtdienst - Rechnung.xlt ist eine Rechnungsvorlage in Excel mit optionaler Datenbankanbindung. Sieht man immer noch sehr oft als Kassensoftware für Krauterläden. - Immer und immer wieder jegliche Art von Zusammenstellungen (Artikel zu Lieferungen, Teile zu Maschinen, Menschen zu Firmen, Dinge zu Sammlungen...). - Ja, Terminkalender ebenfalls. Eine *einfache* Terminplanung in Base würde wohl die meisten Leute optisch nicht ansprechen. Kreuztabellen sind nun mal wirklich Calc's Domäne (Mensch x Stunde, Tag x Monat,...). Die Leute sind oft mit formatierten Tabellenblättern zufriedengestellt, in die sie analog zu Papierplänen hineinschreiben. - Auffallend viele Online-Gamer versuchen ihre Strategie mittels einer Datenbankanwendung zu optimieren. Durchaus vergleichbar mit Resourcenplanung in der Geschäftswelt. Bei Calc ist sofort Ende der Fahnenstange wenn Gruppen von Spielern, alle möglichen Punktsysteme und Währungseinheiten für verschiedene Ausstattungsmerkmale über die Zeit variabel sind. - Ach ja, Sporttabellen sind ein ganz großes Thema. Die Fußball-WM in ZA schreit förmlich nach einer Desktop-Datenbank, in die man auch Tipps zum Spielausgang eintragen kann. Eine Datenbank, in die man in 4 Jahren die nächsten Gruppenaufstellungen binnen Minuten eingeben kann anstatt sie aus Browsern nach Calc zu kopieren, was regelmäßig in Weinkrämpfen endet. - Und zum Schluss das aller-allerwichtigste: Es wäre einfach zu schön, wenn Base CSV-Dateien editierbar machen könnte, so dass dieselben Trennzeichen und Zahlenformate wieder auf der Festplatte landen. Schließlich ist CSV ein Datenbankaustauschformat, kommt meistens auch aus irgendwelchen Datenbanken, die nicht im verfügbaren Netzwerk bereit stehen. Tabellenkalkulationen sind per se ungeeignet als Texteditoren, weil ihre Funktion darauf beruht, alles als Fließkommazahl zu interpretieren. Selbstverständlich muss eine Tabellenkalkulation Texttabellen einlesen können (und Calc kann das besser als Excel) aber als Tabelleneditor muss das in die sprichwörtliche Hose gehen. Die Einbindung via HSQLDB ist schon mal großartig, scheitert aber an Datumswerten sofern sie nicht ISO sind, Dezimaltrennern sofern sie nicht Punkt sind, und es gibt noch weitere Einschränkungen. - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
