Daten Schleife schneller machen

[alzaimar]

Zitat von Pluto:

Es lässt sich auch nicht alles mit SQL machen...

Aber fast Alles. Man muss nur vom Denken in 'Records' Abstand nehmen und mit Mengen arbeiten. Während Access, Paradox etc. ISAM-Datenbanken sind (die also mit einzelnen Records arbeiten), sind moderne DBMS (mySQL 5, MSSQL, FB, Oracle etc.) mengenbasierte Datenbanken. Das bedeutet, das eine Tabelle als Ganzes betrachtet wird. Die Operationen (Select, update, delete etc.) sind darauf ausgelegt, immer mit der (Teil-)Tabelle als Ganzes zu arbeiten. Sie sind dann nicht wesentlich langsamer, als wenn man immer nur einen Record betrachtet.

1000xInsert ist viel viel langsamer als ein Insert, der 1000 Records auf einmal einfügt, etwa per
insert into Table (field1, field2) select myField1, myField2 from MyTable Und ein Select, das 1000 Records liefert ist viel schneller (fast 1000x) als 1000 selects, die immer nur ein Record abholen.

Es gibt natürlich Fälle, wo man es mit einem einfachen Befehl nicht hinbekommt, dann nimmt man eine temporäre Tabelle. Und wenn es dann nicht geht, kann man immer noch über einen Cursor die zu modifizierende Tabelle durchiterieren (alles z.B. in einer Stored Procedure auf dem Server). Das geht i.A. schneller, als das von Pluto vorgeschlagene Verfahren: Was passiert?
in etwa das hier:

SQL-Code:

Select * from Tabelle
<Verarbeitung im Client>
<-bis hier ist die Welt noch in Ordnung>
Update Tabelle set .....
Update Tabelle set .....
<100000 mal das gleiche Spiel>...
Update Tabelle set .....

Die Verarbeitung im Client ist schneller (aber wirklich nur, wenn für jeden Record sehr komplexe operationen notwendig sind).
Die Übermittlung der Änderungen frisst extrem viel Zeit und belastet den Server und das Netz. Bei 100.000 Datensätzen mit Sicherheit der falsche Ansatz.

Ich persönlich kenne keinen Fall (bitte wörtlich nehmen), wo die clientseitige Verarbeitung (einen richtigen DB-Server vorausgesetzt) schneller ist als die serverseitige Verarbeitung. Diese hat aber einen *entscheidenden* Nachteil in einer Mehrbenutzerumgebung: Sie belastet den Server. Das ist der Grund, warum man die clientseitige Verarbeitung andenken sollte, wenn viele Leute mit der DB arbeiten, bzw. die Verwurstung einer Tabelle sehr oft vorkommt. Dann ist das aber i.A. schlechtes Design.

Verwurstungen sollte man über Trigger realisieren: Dann werden z.B. einzelne Spalten anderer Tabellen immer dann überarbeitet, wenn sich einzelne Einträge ändern. Beispiel: Rechnungen und Rechnungspositionen. Anstatt die Rechnungssumme immer komplett über alle Positionen zu berechnen, kann man auch einen Trigger schreiben, der bei Änderungen an der Tabelle 'Rechnungspositionen' aktiv wird:
Bei INSERT: Addiere den Preis der Rechnungsposition zur Gesamtsumme der Rechnung.
Bei DELETE: Subtrahiere den Preis der Rechnungsposition von der Gesamtsumme der Rechnung.
Bei UPDATE: Subtrahiere den alten Preis und addiere den neuen Preis.

Auf diese Weise hat man immer die korrekte Rechnungssumme (sofern dieses Felder für die direkte Änderung gesperrt sind) und muss nie rechnen. Man bekommt die Rechnungssummen *sofort*, ohne jegliche Zeitverzögerung. Der Preis hierfür ist eine um ein paar Mikrosekunden erhöhte Zeit beim Update der Rechnungspositionstabelle. Na und?