UuugUuug hat geschrieben:* Was die Normalisierung betrifft ist das ein Punkt der normalerweise wichtig ist, das ist mir auch bewusst. Allerdings ist die Menge der Daten so gering dass das nicht wirklich eine Rollen spielen wird.
Du solltest es trotzdem beachten; dadurch wird auch ein kleines Projekt übersichtlicher. Du musst zwar nicht alle Einzelheiten auslagern (z.B. MWSt-Sätze und Historie), aber auf jeden Fall zwischen Stammdaten (Gartenbesitzer) und Verlaufsdaten trennen.
* Von Makroprogrammierung mit Staroffice habe ich garkeinen PLAN.
Es ist sehr gewöhnungsbedürftig, wenn man von einer Hochsprache kommt (erst recht von OOP). Aber auch da kann man sich einarbeiten, z.B. mit der
Makro-Einführung.
Noch nebenbei bemerkt soll es im Anschluss an dieses "PROJEKT" noch eine Java-Umsetzung und eine PHP-Umsetzung geben welche auf die selbe Datenbank zugreifen.
Dann ist unbedingt eine richtige Datenbank zu empfehlen. (Die integrierte HSQLDB ist eine Ein-Platz-Lösung.) Am einfachsten in Base einzubinden ist MySQL; aber ich weiß, dass auch MS-SQL verwendet werden kann.
... an dem Punkt wo ich mit spezifischen Daten aus der Datenbank rechne, das Ergebnis bzw. die Ergebnisse in ein WriterDomument portiere und genau das für jeden Gartenbesitzer automatisieren kann um es dann als Serienbrief zu versenden.
Das ist die übliche Frage nach "Fat Server" und "Fat Client". Ich lasse gerne viel über Trigger und Views (komplett mit JOINs) laufen. In die Views kommen dann entsprechende Berechnungen hinein, und die Serienbriefe greifen auf die Views und nicht auf die eigentlichen Tabellen zu. Stattdessen kann man auch in Base Abfragen erstellen und diese als Datenquelle benutzen.
Habe diesbezüglich kein adäquates Beispiel gefunden das mir da weiter helfen könnte.
Hast du schon einen Blick in die
Base-Einführung und das
Base-Handbuch geworfen? Für beides gibt es Beispieldatenbanken.
Viel Erfolg! Jürgen
[quote="UuugUuug"]* Was die Normalisierung betrifft ist das ein Punkt der normalerweise wichtig ist, das ist mir auch bewusst. Allerdings ist die Menge der Daten so gering dass das nicht wirklich eine Rollen spielen wird.[/quote]
Du solltest es trotzdem beachten; dadurch wird auch ein kleines Projekt übersichtlicher. Du musst zwar nicht alle Einzelheiten auslagern (z.B. MWSt-Sätze und Historie), aber auf jeden Fall zwischen Stammdaten (Gartenbesitzer) und Verlaufsdaten trennen.
[quote]* Von Makroprogrammierung mit Staroffice habe ich garkeinen PLAN.[/quote]
Es ist sehr gewöhnungsbedürftig, wenn man von einer Hochsprache kommt (erst recht von OOP). Aber auch da kann man sich einarbeiten, z.B. mit der [url=http://wiki.documentfoundation.org/images/3/34/01ES_13MakrosEinfuehrung_V33.pdf]Makro-Einführung[/url].
[quote]Noch nebenbei bemerkt soll es im Anschluss an dieses "PROJEKT" noch eine Java-Umsetzung und eine PHP-Umsetzung geben welche auf die selbe Datenbank zugreifen.[/quote]
Dann ist unbedingt eine richtige Datenbank zu empfehlen. (Die integrierte HSQLDB ist eine Ein-Platz-Lösung.) Am einfachsten in Base einzubinden ist MySQL; aber ich weiß, dass auch MS-SQL verwendet werden kann.
[quote]... an dem Punkt wo ich mit spezifischen Daten aus der Datenbank rechne, das Ergebnis bzw. die Ergebnisse in ein WriterDomument portiere und genau das für jeden Gartenbesitzer automatisieren kann um es dann als Serienbrief zu versenden.[/quote]
Das ist die übliche Frage nach "Fat Server" und "Fat Client". Ich lasse gerne viel über Trigger und Views (komplett mit JOINs) laufen. In die Views kommen dann entsprechende Berechnungen hinein, und die Serienbriefe greifen auf die Views und nicht auf die eigentlichen Tabellen zu. Stattdessen kann man auch in Base Abfragen erstellen und diese als Datenquelle benutzen.
[quote]Habe diesbezüglich kein adäquates Beispiel gefunden das mir da weiter helfen könnte.[/quote]
Hast du schon einen Blick in die [url=http://wiki.documentfoundation.org/images/2/29/01ES_08BaseEinfuehrung_V33.pdf]Base-Einführung[/url] und das [url=http://wiki.documentfoundation.org/images/d/d4/06_BH_Gesamtband_V35_einseitig.pdf]Base-Handbuch[/url] geworfen? Für beides gibt es Beispieldatenbanken.
Viel Erfolg! Jürgen