Statistik zu welchem Zeitpunkt berechnen?

cycap · 12.10.2007, 14:06

Hallo Leute,

ich muss demnächst sich ständig aktualisierende Statistiken realisieren und bin mir noch nicht sicher wie ich das ganze machen soll. Ich geb mal nen vereinfachtes Beispiel um zu zeigen welche Frage sich mit stellt.

Code:

User | Zeit | Verdienst
15 | 20070815 | 115
15 | 20070816 | 132

Soll ich jetzt die Summe und Durchschnittssumme beim INSERT/UPDATE in die Tabelle in eine andere Tabelle schreiben? Oder soll ich die jedes mal neu berechnen?

Schonmal im Vorraus vielen Dank für das mitteilen Eurer Meinung

Gruß
CyCap

agrajag · 12.10.2007, 14:19

Ich würde sagen, dass kann man so pauschal nicht sagen.

Wenn es viele Einträge in dieser Beispieltabelle gibt und die angesprochene Statistik oft aufgerufen wird dann würde ich die Auswertungen zusätzlich in eine zweite Tabelle schreiben.

Wenn die Statistik aber nur für dich zugänglich ist und nicht oft aufgerufen wird würde ich es jedesmal berechnen lassen...

lazydog · 12.10.2007, 14:26

Zitat:

Zitat von Agrajag

Ich würde sagen, dass kann man so pauschal nicht sagen

Doch, das kann man pauschal sagen: berechnete Daten haben in einer relationalen DB nichts zu suchen.
Sollte aus Performance-Gründen einmal eine solche Denormalisierung in Ausnahmefällen nötig sein, so sollte sie mit Triggers und Stored Procedures so gestaltet sein, dass sie nach aussen nicht sichtbar wird.

Zergling-new · 12.10.2007, 14:26

Ich würde den Informationsverlust so gering wie möglich halten, außerdem können sich mit der Zeit nicht unbeträchtliche Rundungsfehler einschleichen, wenn du den Durchschnittswert jedes mal neu berechnest und schreibst. Lieber dynamisch.
Die Resourcen die man dafür braucht sind vermutlich vernachläßigbar.

cycap · 12.10.2007, 15:02

Es geht ja um viel komplexere Rechnungen als diese hier. Habe es aus Verständnisgründen bis aufs minimum vereinfacht.

Mir geht es darum das die Rechnung viele Variablen hat und das Ergebnis auf mehreren Seiten gebraucht wird. Wenn ich die Berechnung nur bei INSERT/UPDATE durchführe und speichere dann hab ich das Ergebnis da und kannst millionen mal aufrufen. Mach ich das aber nicht so muss ich die Rechnung millionen mal ausführen und das wird sicherlich Performance Probleme geben oder meint ihr nicht?

Also die Rechnung sieht so aus das ich Summen und Durchschnittswerte pro Tag ausrechne und unterscheide zwischen vollen und anteiligen Beträgen wobei der Anteil auch wieder variabel ist und es geht jeweile um einige tausend Datensätze.

EDIT: nicht nur pro Tag sondern auch pro Produkt und Tag

lazydog · 12.10.2007, 15:39

Natürlich musst du schlussendlich selber herausfinden, was besser ist. Wahrscheinlich wirst du um ein paar Messungen nicht herumkommen.
Aber ich würde, wenn immer möglich, keine berechneten Daten in der DB ablegen. Wenn du die Berechnungslogik in Datenbank-Funktionen speicherst - vielleicht genügen sogar Views - sollte das performant genug sein.
Im andern Fall musst du dafür sorgen, dass bei jeder Änderung auch die Berechnung neu durchgeführt wird. Mal abgesehen davon, dass die DB dann natürlich nicht mehr normalisiert ist.

agrajag · 12.10.2007, 15:47

Zitat:

Zitat von lazydog

Aber ich würde, wenn immer möglich, keine berechneten Daten in der DB ablegen. Wenn du die Berechnungslogik in Datenbank-Funktionen speicherst - vielleicht genügen sogar Views - sollte das performant genug sein.

Views? die sollten doch Performance-mäßig garnichts bringen. Höchstens Materialized views aber die gibt es glaube ich nur bei Oracle?

Zitat:

Im andern Fall musst du dafür sorgen, dass bei jeder Änderung auch die Berechnung neu durchgeführt wird. Mal abgesehen davon, dass die DB dann natürlich nicht mehr normalisiert ist.

Es kommt drauf an was das für eine Statistik ist und wie aktuell die Daten sein müssen. Wahrscheinlich reicht es vollkommen einmal täglich ein Script zu starten, dass die Daten berechnet und Cachet....
(man kanns eben nicht Pauschal sagen

)

Mich würde es jetzt aber doch mal intressieren wie du das mit Triggern und Stored Procedures gemeint hast? Du meinst für den Fall, dass die Statistik immer aktuell sein soll und du dann mit einem Trigger abfängst wenn was geändert wird?
Ich glaube nicht, dass er so aktuelle Statistiken braucht. Und dass es manchmal sinnvoll sein kann die Normalisierung zu brechen hast du ja auch schon erwähnt. Ich bleib dabei:
Pauschal kann man das nicht sagen.

dr.e. · 12.10.2007, 23:49

@Agrajag:

Zitat:

Views? die sollten doch Performance-mäßig garnichts bringen. Höchstens Materialized views aber die gibt es glaube ich nur bei Oracle?

Materialized Views sind ein Datenhaltungskonzept, das man auf jeder relationalen Datenbank betreiben können sollte.

@ALL:
Grundsätzlich bleibt zu diesem Anwendungsfall zu sagen, dass man es auf den Fall ankommen lassen sollte/muss. Nehmen wir ein Profil in einem Forum. Hier müsste jedesmal bei der Ausgabe eines Threads die Anzahl der Beiträge eines Benutzers gezählt werden, was über eine "posts"-Tabelle sicher eine Zeit benötigt, selbst wenn es Indizes gibt. Denn hier bleibt nichts anderes übrig als ein

Code:

SELECT COUNT(*) AS count WHERE username = 'cycap';

zu machen und das für alle Benutzer, die im Thread auf der entsprechenden Seite gepostet haben. Hier einmal beim Speichern eines Beitrags den Count zu erhöhen, steigert die Performance schon mal gewaltig. Arbeitet man dann noch mit dedizierten Mapper-Schichten, die ein Objekt-Caching implementieren, erreicht man optimale Ergebnisse bei sinnvoller Dynamik.

Man muss also IMHO zunächst die Komplexität der Berechung und die Performance derselben beurteilen um eine Entscheidung treffen zu können. Sorry Zergling, aber da muss ich dir - und das kommt eigentlich nie vor - wiedersprechen.

agrajag · 13.10.2007, 00:13

Zitat:

Zitat von dr.e.

Zitat:

[...]Höchstens Materialized views aber die gibt es glaube ich nur bei Oracle?

Materialized Views sind ein Datenhaltungskonzept, das man auf jeder relationalen Datenbank betreiben können sollte.

Sollte ja, aber das heißt ja nicht, dass es so ist.

Ich hab noch nicht mit sovielen unterschiedlichen DBMS Kontakt gehabt und kenne Materialized Views nur in Oracle bzw. weiß dass sie bei MySQl (noch) nicht unterstützt werden (oder hat sich das mittlerweile geändert?). Ich hab jetzt aber mal etwas gesucht und PostgreSQL unterstützt es auch.

Scheint also wohl eher so zu sein, dass mal wieder nur MySQL Materialized Views nicht kennt

. Asche auf mein Haupt.

dr.e. · 13.10.2007, 00:23

Nich ganz fürchte ich.

Es gibt Leute, die das möglich gemacht haben. Guckst du http://forums.mysql.com/read.php?100...9245#msg-59245. Ein weiterer Artikel findet sich unter http://pure.rednoize.com/2005/11/12/...iews-in-mysql/. Ich muss gestehen, ich habe mir die Artikel nicht genau durchgelesen, aber es fanden sich auf den ersten Blick sinnvolle Inhalte darin.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
[Erledigt] Sporttabelle aus Ergebnissen berechnen		Datenbanken	6	13.03.2006 20:37
Zanox Statistik??	Diego1978	Beitragsarchiv	2	26.11.2005 18:55
Off-Topic Beiträge zählen?? (Statistik)	stf.stream	Off-Topic Diskussionen	54	17.03.2005 19:49
statistik php-web	Sonja	PHP-Fortgeschrittene	2	04.03.2005 10:06
Help, Zahlen aus DB berechnen		PHP Tipps 2004-2	6	29.12.2004 17:55

12.10.2007, 14:06
cycap Moderator Registriert seit: 13.02.2008 Beiträge: 6.816 PHP-Kenntnisse: Fortgeschritten	Statistik zu welchem Zeitpunkt berechnen? Hallo Leute, ich muss demnächst sich ständig aktualisierende Statistiken realisieren und bin mir noch nicht sicher wie ich das ganze machen soll. Ich geb mal nen vereinfachtes Beispiel um zu zeigen welche Frage sich mit stellt. Code: User \| Zeit \| Verdienst 15 \| 20070815 \| 115 15 \| 20070816 \| 132 Soll ich jetzt die Summe und Durchschnittssumme beim INSERT/UPDATE in die Tabelle in eine andere Tabelle schreiben? Oder soll ich die jedes mal neu berechnen? Schonmal im Vorraus vielen Dank für das mitteilen Eurer Meinung Gruß CyCap


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

12.10.2007, 14:19
agrajag Moderator Registriert seit: 02.10.2006 Beiträge: 3.820 PHP-Kenntnisse: Fortgeschritten	Ich würde sagen, dass kann man so pauschal nicht sagen. Wenn es viele Einträge in dieser Beispieltabelle gibt und die angesprochene Statistik oft aufgerufen wird dann würde ich die Auswertungen zusätzlich in eine zweite Tabelle schreiben. Wenn die Statistik aber nur für dich zugänglich ist und nicht oft aufgerufen wird würde ich es jedesmal berechnen lassen... __________________ Today you...Tomorrow me.

12.10.2007, 14:26
Zergling-new Erfahrener Benutzer Registriert seit: 21.05.2008 Beiträge: 9.937	Ich würde den Informationsverlust so gering wie möglich halten, außerdem können sich mit der Zeit nicht unbeträchtliche Rundungsfehler einschleichen, wenn du den Durchschnittswert jedes mal neu berechnest und schreibst. Lieber dynamisch. Die Resourcen die man dafür braucht sind vermutlich vernachläßigbar.

12.10.2007, 15:02
cycap Moderator Registriert seit: 13.02.2008 Beiträge: 6.816 PHP-Kenntnisse: Fortgeschritten	Es geht ja um viel komplexere Rechnungen als diese hier. Habe es aus Verständnisgründen bis aufs minimum vereinfacht. Mir geht es darum das die Rechnung viele Variablen hat und das Ergebnis auf mehreren Seiten gebraucht wird. Wenn ich die Berechnung nur bei INSERT/UPDATE durchführe und speichere dann hab ich das Ergebnis da und kannst millionen mal aufrufen. Mach ich das aber nicht so muss ich die Rechnung millionen mal ausführen und das wird sicherlich Performance Probleme geben oder meint ihr nicht? Also die Rechnung sieht so aus das ich Summen und Durchschnittswerte pro Tag ausrechne und unterscheide zwischen vollen und anteiligen Beträgen wobei der Anteil auch wieder variabel ist und es geht jeweile um einige tausend Datensätze. EDIT: nicht nur pro Tag sondern auch pro Produkt und Tag

12.10.2007, 15:39
lazydog Erfahrener Benutzer Registriert seit: 02.04.2008 Beiträge: 4.032	Natürlich musst du schlussendlich selber herausfinden, was besser ist. Wahrscheinlich wirst du um ein paar Messungen nicht herumkommen. Aber ich würde, wenn immer möglich, keine berechneten Daten in der DB ablegen. Wenn du die Berechnungslogik in Datenbank-Funktionen speicherst - vielleicht genügen sogar Views - sollte das performant genug sein. Im andern Fall musst du dafür sorgen, dass bei jeder Änderung auch die Berechnung neu durchgeführt wird. Mal abgesehen davon, dass die DB dann natürlich nicht mehr normalisiert ist. __________________ Gruss L

13.10.2007, 00:23
dr.e. Moderator und Wett-König Registriert seit: 21.05.2008 Beiträge: 3.654 PHP-Kenntnisse: Fortgeschritten	Nich ganz fürchte ich. Es gibt Leute, die das möglich gemacht haben. Guckst du http://forums.mysql.com/read.php?100...9245#msg-59245. Ein weiterer Artikel findet sich unter http://pure.rednoize.com/2005/11/12/...iews-in-mysql/. Ich muss gestehen, ich habe mir die Artikel nicht genau durchgelesen, aber es fanden sich auf den ersten Blick sinnvolle Inhalte darin. __________________ Viele Grüße, Dr.E. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Think about software design before you start to write code! 2. Discuss and review it together with experts! 3. Choose good tools (-> Adventure PHP Framework (APF))! 4. Write clean and reusable software only! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~