[HBF] Re: Heimbrausoftware

[Peter Wiedermann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hallo braugemeinde


> bevor Ihr darüber diskutiert wie Ihr Eure Software implementiert (die
> Java-Idee ist mir sympathisch, von Skript-Sprachen rate ich eher ab, und was
> eine etwaige DB angeht, findet Ihr den Einsatz einer Vollblut-SQL-DB im
> Angesicht der Aufgabe einer Rezept-Verwaltung nicht leicht übertrieben?),

ich glaube in punkto java sind wir uns alle einig.
also ich waere fuer eine "Vollblut-SQL-DB" aus gruenden die dann im
unteren teil noch naeher erklaert werden.


> solltet Ihr Euch ERST mal grob überlegen, was die Software können soll,
> insbesondere was die Software MEHR können soll als das, was Huberts
> Rechenblatt eh' schon kann.  Mein Eindruck ist, daß darüber noch keine
> Einigkeit besteht (naja, im Zweifelsfall bestimmen das natürlich die
> Implementierer, aber die gibt's bis jetzt ja noch nicht).  In diesem Sinn
> sollte jeder, der mit dem Gedanken einer Implementierung spielt, einmal
> präzise sagen, worin eigentlich die Leistung der Software liegen sollte.
>
stimmt. wir muessen ein pflichtenheft anlegen.
1. welche berechungne sind notwendig
2. welche sonderfunktionen sind sinnvoll


> Dann ist zu überlegen, ob das Mehr den Aufwand auch lohnt; wenn die Software
> im Prinzip nur dasselbe macht, was das Rechenblatt bereits macht plus, sagen
> wir mal, Einheitenumrechnung, dann fände ich es etwas zeifelhaft, den ganzen
> Aufwand zu betreiben.

um das zu beantworten werd ich gleich mal einige meiner "forderungen" fuer
punkt 2. umschreiben:

die software haette neben der vereinfachung gegenueber der
tabellenkalkulation natuerlich noch mehrere funktionen.
ich wuerde mir zb wuenschen, das nach der planung ein brauprotokoll
in verschiedenen formaten (html, postscript waeren fuer mich zb nuetzlich)
ausgegeben werden kann. beim brauen selbst werden die meisten keinen
rechner zur verfuegung haben, dh ein protokoll macht sinn. htmlformat
waere zb zur veroeffentlichung ganz sinnvoll..... also da werden sicher
noch viele wuensche offen sein.
(jetzt komme ich auf die vorteile der db zu sprechen:)
in der datenabnk koennen neben rezepten dann zb auch protokolldaten
abgelegt werden. dh innerhalb der datenbank entstehen bereits
zusammenhaenge zwischen unterschiedlichen datenstrukturen.
wenn man dann ueber diese daten statistiken (zb messwertabweichungen vom
rezept in abhaengigkeit des braudatums... ) laufen lassen will (und eben
nach bestimmten zusammenahengen filtern muss) wirds mit dateien schon
unsauberer.

ausserdem werden daten in einer db nicht automatisch nach dem "tod" des
programms zu "karteileichen", weil das datenformat zusehr auf das problem
des programs optimiert war.
man kann jederzeit programme schreiben die ebenfalls darauf zugreifen, und
eigentlicheinem ganz anderen zwecken dienen...
kurz: ich fuehl mich besser wenn ich wertvolle daten in einem format parat
habe das nicht nur ich kenne, und das sich nicht nur bei mir bewehrt hat.

ist die installation eines mysqld (angesichts dieses nutzens) wirklich so
schlimm?

ein programm haette also gegenueber der tabellenkalkualtion den
vorteil
1. einen brauchbaren datenhaufen zu hinterlasen
2. leichter verstaendlich zu sein (mit der idee der berrechnugssaetze in
der db wuerde es auch nciht allzuviel an flexibilitaet verlieren)
3. sonderfunktionen wie zb  (ueber die wir uns noch einigen muessen

schaut jetzt alles viel aus... aber ich finde man sollte mal ideen
und vorschlaege sammeln um zu sehen was man alles machen koennte, und was
sinn ergeben wuerde.
man muss ja dann nicht alles tatseachlich in die tat umsetzen.

gut sud
peter

====================================================
Peter Wiedermann <peter.wiedermann at gmx.at>
gpg public key: http://geldspeicher.entenhausen.at
====================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE95BB3NCZnZhPzqWURAgFqAJ0SVW36pp2u6tPcl6k3cKm0Lq4HsQCghm9C
YHBTepcKARV2OA1v4Zh165U=
=EHtF
-----END PGP SIGNATURE-----