> Meine Erfahrung zeigen das ein SUM oder COUNT z.B. sich nicht in der > Performance negativ auf ein Select auswirken, egal wie oft man es > ben�tigt.
Es wirkt sich logischerweise aus, weil mehr Datens�tze gelesen werden m�ssen, um das Ergebnis zu bilden, als bei einem einfachen SELECT. Bei kleinen Tabellen ist dies f�r den Benutzer nicht oder nur kaum sp�rbar, aber sehr wohl als Belastung auf dem SQL-Server. Der Benutzer wird es deutlich sp�ren bei gro�en Tabellen und bei einer eventuell erforderlichen Gruppierung. In einer unserer Anwendungen werden arbeitst�glich ca. 900 Auftr�ge mit 1:n Positionen entgegengenommen. Ohne Summenfelder in einer extra Tabelle w�rden die Auswertung f�r das letzte halbe Jahr auch beim Einsatz einer Stored Procedure circa 1,5 Minuten dauern. Mit der permanenten Summenbildung hat er die Daten sofort auf dem Bildschirm. > Ich denke es entspricht nicht mal der 2. Normalform wenn man die Summen separat abspeichert. Das interessiert den Kunden nicht. Der will auf schnellste Art und Weise Ergebnisse sehen - und danach bewertet er auch die Leistung des Programms. Ich gebe allen Recht, die sagen, unproblematisch sei eine solche L�sung nicht - weil man nat�rlich immer daf�r sorgen muss, da� die summierten Zahlen aktuell sind. Mit der richtigen Datenbank (also eine, die auch Trigger kann), ist dies aber leicht sicherstellen. Tsch��, Joachim ~~~~~~~~~~~~~~~~~~~~~~~~~~~sponsored by United Planet~~~~~~~~~~~~~~~~~ Intrexx.BizWalker + ODBC/OLEDB-Daten = ASP-Formular ATTACK! Download Intrexx CRM-Studio Now! http://www.intrexx.com _______________________________________________ Database.asp mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/database.asp
