Am Mittwoch, 12. November 2003 00:08 schrieb Al Bogner: [...]
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. [...] 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.
Damit ist aber immer noch nicht die Konsistenz der Daten gewährleistet - zu dem Zeitpunkt, an dem die DB die Daten abholt, können sie ja gerade von einem anderen Nutzer korrumpiert worden sein.
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.
Nicht skalier- / erweiterbar by Design - IMHO eine kurzsichtige Herangehensweise, aber das ist Deine Sache. Ich habe die Erfahrung gemacht, dass in jeder Anwendung, die eine Multiuser-Datenbank benutzt, das DB-Design der Punkt ist, worüber man am längsten und zuerst nachdenken sollte. Jede nachträgliche Änderung potenziert den Aufwand. Jan P.S.: Script ist unterwegs.