Erweiterte Statistiken

[String]

Hallo zusammen,

ich würde gerne ein Projekt (Online-Shop) von mir dahingehend erweitern, dass man auslesen kann, wann welcher Artikel wie oft verkauft wurde.

Im Prinzip ist das ja kein Problem. Allerdings wird dann irgendwann die Datenbank platzen, wenn ich für jeden verkauften Artikel einen Eintrag mache, wenn dieser verkauft wird. Also in etwa so:

Datum	ArtikelNr	ArtikelName
21.01.2013	abc	Name
21.01.2013	efg	Name2

usw.

Wenn ich jetzt daran denke, dass es durchaus vorkommen kann, dass am Tag einige hunderte Artikel verkauft werden können macht das in einem Jahr (ca. 400 Artikel x 365 Tage) 150.000 Einträge im Jahr.

Aber es muss da doch eine klevere Lösung geben oder?
Gleiches würde ja für einzelne Seitenaufrufe gelten. Wenn ich aber jetzt daran denke, 30.000 Seitenaufrufe am Tag in eine Tabelle zu schreiben, kann ich MySQL irgendwann vergessen

PS: Die Namen müsste man mit speichern, da diese sich ja irgendwann ändern könnten und so die Statistik verfälschen würden

Gruß
paD

 

[tombe]

Was die Artikelstatistik angeht ist die Frage welche Daten du jetzt bereits speicherst. Wenn etwas bestellt wird, dann hast du doch den Artikel, die Menge und das Datum. Wozu dann nochmal das gleiche in einer anderen Tabelle speichern?

Bei 30.000 Seitenaufrufen am Tag speicherst du aber nicht 30.000 Datensätze.

Seite  - Datum  - Zugriffe
seite1 - 21.01. - 100
seite2 - 21.01. - 150

 

[String]

Hey, danke für die flotte Antwort.

Also aktuell speichern wir es eben nicht so. Es wird nur die gesamte Bestellung gespeichert.

Nein, wir speichern auch bei 30.000 Seitenaufrufe keine 30.000 Datensätze.

Und genau darum geht es ja. Wie könnte man das speichern OHNE diese 30.000 Datensätze?
Wie könnte ich also 30.000 Seitenaufrufe speichern, ohne 30.000 Datensätze?

Oder anders gesagt, wie speichere ich 30.000 Seitenaufrufe / Tag sinnvoll?

Wenn ich an deine Struktur denke, kann ich mir gut vorstellen, die Datenbank explodiert genau so schnell.
Bei 30.000 Aufrufe auf aktuell ca. 9.000 Einzel-Seiten. Macht am Tag immer noch (max.) 9.000 Einträge am Tag (sofern jede Seite aufgerufen wird).

-> Wie ich merke wäre eine Statistik noch komplizierter..

paD

 

[tombe]

Ich kenne deine/eure Homepage nicht aber ich kann mir nicht vorstellen das ihr 9.000 Seiten (Dateien) habt!

Wenn es einen Shop gibt, dann wird die "Shopseite" vielleicht mit X verschiedenen Anfragen aufgerufen.

Wie schon oben geschrieben würde ich für jede Seite (HTML-/PHP-Datei) einen Eintrag am Tag machen und da die Gesamtzahl der Aufrufe speichern.

Und wenn ihr die gesamte Bestellung speichert, dann könnt ihr doch aus dieser Tabelle die gewünschten Daten für die Artikelstatistik ermitteln.

 

[alxy]

Die Bestellungen abzuspeichern wird wohl kein Problem für die DB darstellen.
Jeden seitenaufruf zu loggen ist mMn sinnfrei.

 

[String]

Hey hey,

okay, gehen wir jetzt von den Statistiken aus, da es sich dort ja anscheinend wesentlich krasser auswirkt

Genau, wie du sagtest, das sind keine 9.000 Dateien, sondern wenn es hoch kommt knappe 100.
Aber genau wie du schriebst, wird die Datei halt mit verschiedenen Parametern aufgerufen. Wenn ich also wissen wollen würde, wie oft ein einzelner "Artikel / ForenBeitrag / BlogEintrag..." gelesen wurde, würde mir nichts anderes übrig bleiben als die Parameter mit zu speichern.

So kämen wir doch auf die maximalen Einträge am Tag von ca. 9.000 St. (Die Zahl ist relativ aus der Luft gegriffen, aber ist ja ein gutes Beispiel )

Was mir leider nicht ganz schlüssig ist.... Wie könnte ich dann sinnvoll Referrer und Co speichern? Wenn ich wissen wollen würde, welcher Artikel der interessanteste in einer Rubrik ist, müsste ich den Referrer auslesen und speichern um nachher auswerten zu können "woher die Leute kamen" ?

Beste Grüße
paD

 

[tombe]

Also wenn man davon ausgeht das eine mySQL Tabelle (je nach Betriebssystem) zwischen 2GB und 16TB groß sein kann, dann denke ich nicht das du das Limit so schnell erreichen wirst.

Wenn du es wirklich so genau protokollieren willst, da bleibt natürlich nichts anderes übrig als jeden Seitenaufruf separat zu speichern. Was ich aber machen würde ist das ich für jeden Monat eine eigene Tabelle erstellen würde.

Dann kommt im Bezug auf die Datenmenge auch noch dazu das vermutlich niemand mehr wissen will wie oft die Seite XY vor 2 Jahren aufgerufen wurde. Soll heißen du kannst nach einer gewissen Zeit ja auch wieder was löschen.

Bevor du aber damit anfängst sollte erstmal klar sein wie oft welche Statistik auch wirklich gelesen wird. Nicht das es nachher tausende von Einträge gibt und keiner wertet es aus!

 

[String]

Hm.. du hast mich da auf ein paar gute Ideen gebracht.
Die frage, welche Seite wurde genau wie oft vor 6 Monaten aufgerufen ist sehr uninteressant.
Die Daten aber, wie häufig aktuell etwas aufgerufen wurde schon.

Man könnte also schon jeden Seitenaufruf loggen. Und einmal die Woche ein Cronjob laufen lassen, welcher diese in eine neue Tabelle schreibt. Also global zusammengefasst. So wird sich die Datenbank in grenzen halten und das Auswerten braucht nicht gerade Stunden, weil er Zig Einträge auswerten muss

Was meint ihr, ist so etwas eine Idee?

Gruß
paD