Mailinglist Archive: opensuse-de (4880 mails)
| < Previous | Next > |
Re: SQL Syntax in MySQL
- From: Jan.Trippler@xxxxxxxxxxx (Jan Trippler)
- Date: Wed, 12 Nov 2003 02:04:10 +0100
- Message-id: <200311120204.10679.Jan.Trippler@xxxxxxxxxxx>
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.
[...]
> 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.
| < Previous | Next > |