Am Dienstag, 11. November 2003 01:11 schrieb Jan Trippler:
Am Dienstag, 11. November 2003 00:10 schrieb Al Bogner: [...]
Ich will eigentlich gar nicht so viel. Aber, ich will das UI nicht per Browser realisieren. Bei Verlassen eines Feldes soll die Änderung in der DB erfolgen und nicht erst, wenn ich mit einem "Knopf" die Datenübernahme in die DB befehle. Einen Trigger werde ich am
Hast Du Dir das auch richtig überlegt? Du vervielfachst den Traffic im Netz und die Belastung des DB-Servers und bringst Deine Daten in Gefahr.
Der Traffic im lokalen Netz ist mir total egal. Dem Netz ist sowieso meist langweilig. Denk an ein Small-Office-Büro mit ein paar kleinen Datenbanken von ein paar tausenden Datensätzen und dann gibt es noch ein paar größere DBs von vielleicht 10-20MB. Also keine wirkliche Herausforderung für eine DB.
Beispiel1: Kunde *Ich_zock_Dich_ab_AG*; Kreditlimit alt 1.000,-, neu 100.000,-; <ENTER> - *ups*, sollte ja 100,00 heissen; zurück. In der Zwischenzeit hat der Kunde erfolgreich Deine Firma gekauft.
Mir fällt hier keine ähnlich kritische Situation ein. Außerdem kann man immer Fehler entdecken, auch nach dem Abschicken. Ich gebe dir aber recht, dass man sich das je _nach_ DB-Anwendung gut überlegen soll. Hier gibt es zB eine Adress-DB für einige Leute und allein schon die gleichzeitige Verwendung dieser DB ist eher die Ausnahme. Wahrscheinlich verdienen die Datenbanken hier die Bezeichnung gar nicht. Wenn du willst, kannst du auch dazu gemeinsam genutzter strukturierter Notizzettel sagen.
Beispiel2: Abhängigkeiten zwischen Feldern - Wenn älter als 18 Jahre, dann *Hardcore*-Checkbox aktivieren. Jetzt ändere bei aktiviertem *Hardcore*-Feld das Alter auf 16 - entweder brüllt die DB (ach ne - das kann mysql ja eh nicht ;) oder aber Du hast gerade gegen das Jugenschutzgesetz verstoßen und morgen steht die Polizei vor Deiner Tür ;) Willst Du sowas alles in der Anwendung abfangen? Bei _jedem_ relevanten Feld? Jedesmal mit DB-Insert / -Update?
Auch diese Situation gibt es hier in ähnlicher Weise nicht.
DB-Frontend wohl haben wollen, d.h. bei Verlassen eines Feldes, soll ein Shellscript oder was immer ausgeführt werden. Die
Hast Du Dir mal Gedanken über die Performance gemacht, wenn Du bei jedem Klick Scripts ablaufen lässt?
Bei _jedem_ Klick muß ja ein Script nicht ablaufen. Ich denke da zB an die Übertragung der Daten ins Handy. Mysql braucht dafür selber 1(?) Sekunde und das Schreiben ins Handy für alle Bereiche dauert ca. 1 Minute. Es ist vollkommen egal, ob zu dieser Zeit von jemand anderem eine neue Adress eingegeben wird oder nicht. Die Eingabe der Kriterien zur Übertragung erfolgt durch den, dem das Handy gehört. Ich experimentiere mit ca. 20.000 Datensätzen und wundere mich, was ich da für "Unfug" anstellen kann, ohne dass die Performance leidet. Alles was in ein paar Sekunden erledigt ist, ist ok. Bitte denke daran, hier geht es um eine DB-Migration im kleinen Bereich und entscheidend ist mal, dass all das gemacht werden kann, was bis jetzt schon immer funktionierte. Einerseits gibt es das optimale DB-Design, worüber man viel nachdenken muß und andererseits muß sich natürlich auch der Aufwand dafür rechtfertigen. IMO ist es wichtig zu wissen, dass man einen Kompromiß eingegangen ist.
Wenn es Dir erstmal um das Handling des DB-Zugriffs geht, kannst Du von mir ein paar perl-DBI-Schnipsel haben (wobei ich nicht so recht glauben mag, dass es da keine Beispiele z. B. auf cpan.org gibt). Da ist aber keine GUI-Programmierung drin. Im Linux-Magazin gab es auch schon des öfteren ausführliche Artikel (Perl-Snapshot) zu diesem Thema.
Schickst du mir das bitte per PM. Bei cpan habe ich gesucht, bin aber nicht so fündig geworden. Theoretisch fand ich http://guido.sourceforge.net/index.php http://search.cpan.org/~jettero/MySQL-GUI-0.33/GUI.pm http://pythoncard.sourceforge.net/ könnte das sein, wonach ich suche. Ich habe noch ein bißchen Zeit bis ich mich wirklich für eine Programmiersprache entscheiden muß. Python drängt sich in letzter Zeit immer etwas vor. Al