Hallo, On Fri, 12 Feb 2010 15:51:16 +0100 Ernst Hügli wrote: > Am 12.02.2010 15:25, schrieb Andreas 'ads' Scherbaum: > > > > Ich würde die Datenbank so einfach aufbauen, dass sie überall läuft. > > Es ist niemandem geholfen, wenn die Beispieldatenbank so komplex > > gestaltet ist, dass der Anwender zwangsweise an eine bestimmte > > Datenbank gebunden ist. > > > Meines Wissens ist Base nicht mehrplatzfähig - also zeigen sich schon > gewisse Unterschiede! Ferner ist die Oberfläche nicht bei allen DB's > gleich. Also, es gibt schon Unterschiede.
Base selbst nicht. Aber die verwendete Datenbank kann es sein. Wenn man nur die interne Datenbank verwendet, klappt das natürlich nicht. Verwendet man eine im Netzwerk verfügbare SQL-Datenbank, funktioniert das ohne Probleme. Die Oberfläche der Datenbank kann und sollte Base selbst sein, das klappt wunderbar. Bei den drei angesprochenen Datenbanken HSQLDB, MySQL und PostgreSQL kann man die SQL-Befehle über Base absetzen. Schließlich sollen die Anwender in dem Zug lernen, mit Base umzugehen, oder? > > Mir fallen auf Anhieb einige Probleme aus dem Bereich ein, die > > entweder nur schwer zu lösen sind (free-busy, überlappende Termine, > > wiederholende Termine, unregelmäßige Termine) oder eine Menge > > Detailwissen und Skalierbarkeit erfordern. > > > Detailwissen über Terminkalender? Wohl kaum! Du meinst wohl eher > Detailkenntnisse in DB-Entwicklung - das ist ja gerade das Spannende! Das Problem das ich dabei sehe: wollen wir dem geneigten Anwender einen tiefgreifenden Kurs in SQL und Datenbankdesign (und den braucht es dafür) liefern oder einen Kurs in OpenOffice Base? Was ist wichtiger? Für einen Kalender muss man sich quasi vom Start weg Gedanken über Benutzer, Zugriffsrechte (lesend, schreibend), das Handling überlappender Termine ect. machen. Das ganze pro Kalendernutzer. Ich als DBA und Trainer wüsste aus dem Stehgreif nicht, wie ich so etwas in einer SQL-Datenbank mit Bordmitteln sauber abbilden könnte. Wenn das ganze jedoch nicht von Anfang an richtig abgebildet ist, dann ist die ganze Aktion wertlos - dann muss man dem Anwender später erklären, warum die anfangs verwendete Struktur nun doch nicht gut ist. Ich habe nichts gegen einen Datenbankkurs, aber dafür sollten wir einen getrennten Thread aufmachen ;-) > > Außerdem: einen Terminkalender bringt jede bessere Office-Suite > > oder Groupware-Lösung mit, außerdem gibt es die "in fertig" > > massenhaft im Web. Wieso sollte man an der Stelle das Rad neu > > erfinden? Als Übungsbeispiel kann man das auch nur begrenzt > > verwenden, weil es in vielen Firmen schon einen Kalender gibt und > > demzufolge andere Projekte anstehen. Man müsste die Beispiele dann > > erst umständlich auf sein eigenes Projekt umarbeiten. > > > Das gilt wahrscheinlich für *jedes* Projekt - und wenn nicht: > spätestens wenn es als Übungsbeispiel vorhanden ist, dann ist es > gelöst!! Nein. Speziell bei einem Kalender kommen quasi sofort Fragen nach CalDAV (RFC 4791[1]) auf, was man weitgehend komplett mit unterstützen müsste. Ohne diese grundlegenden Dinge ist das eine schöne Übung, aber weitgehend wertlos für den Produktiveinsatz. 1: http://tools.ietf.org/html/rfc4791 > Insbesondere gilt dieser Einwand auch für > Nordwind/Handelsfirma. Ich bin nicht dagegen, ein anderes Thema zu > suchen, aber es müsste - soll es denn Sinn machen - meine Kriterien > erfüllen. Insbesondere beharre ich darauf, dass das Problem von einer > Mehrzahl der Anwender auch inhaltlich verstanden werden muss. Und das > ist bei einer Handelsfirma schlicht nicht der Fall. Der Einwand ist berechtigt. Im Gegenzug stellt sich die Frage, warum es für die Verwaltung von Firmen keine vernünftige, kleine Lösung am Markt gibt. Da bastelt sich jeder sein eigenes Ding, meistens mehr schlecht als Recht. Die größeren Firmen greifen zu Anbietern wie Peoplesoft/Oracle oder SAP. Mit gemischtem Erfolg und Preis. Bei einer Demo, die sich irgendwie um eine Firma dreht (das genaue Thema ist egal), hätte man noch einen weiteren Vorteil: man könnte notwendiges, aber bisher nicht vorhandenes Wissen vermitteln. Außerdem könnte man Schulklassen oder Wirtschaftsstudiengänge ins Boot bekommen, die an so einem Modell mitarbeiten. > Beispiel gefällig? Als Unternehmer muss ich aber letztendlich genau dieses Wissen aufbauen. Ich habe selber Kunden in mehreren europäischen Ländern und musste vorab meinen Steuerberater kontaktieren, um mich mit den Details auseinanderzusetzen. Da komme ich also nicht drumherum. Um auf den Einwand zurückzukommen: Ich hänge nicht an der Idee einer Beispielfirma, jedes andere praktikable Beispiel ist mir auch recht. Nur bei dem angesprochenen Kalender sehe ich halt mehr "Datenbank" als "Base". In meinen Augen soll die Demo jedoch das Wissen um Base vermitteln. Klar gehört SQL dazu, aber nicht in dem Maße wie es dafür notwendig ist. Ein paar andere, einfache Ideen: - Programm zum Vokabeln lernen (das legt mehr Wert auf die Oberfläche als die Datenbank) - Veranstaltungskalender (ohne Benutzer, dafür mit Features wie Export in verschiedenen Formaten ala (x)HTML) - Bücher/CD/DVD Verwaltung Bis dann -- Andreas 'ads' Scherbaum Failure is not an option. It comes bundled with your Microsoft product. (Ferenc Mantfeld) --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
