nicht angemeldet
Aufbau einer Klickstatistik
Hallo geehrtes Forum,
wie würdet ihr eine Klickstatistik auf einer Datenbank (mySQL) abbilden?
Die Vorgabe: es gibt unbestimmt viele IDs, wovon eine mit einem ausgelösten Klick an die DB gesendet wird (z.B. www.domain.de/klick.pl?id=irgendwas). Zusätzlich zu den Klicks gilt es, abgesendete Formulare zu zählen. Die Formulare senden ebenfalls eine ID.
Am Ende möchte ich eine Übersicht für jede ID erhalten, also wieviele Klicks und abgesendete Formulare gab es am Tag/Monat/gesamt.
Meine Idee ist, eine Tabelle mit drei Spalten zu erstellen: Datum, Klicks und Forms. Bei jedem Klick wird die mitgesandte ID in das Feld 'Klicks' geschrieben. Entsprechend wird bei jedem Formular die ID in das Feld 'Forms' geschrieben.
Für die Übersicht erstelle ich ein Script (Perl), welches die gesamte Tabelle einliest, die gewünschte ID in den Feldern findet und in einem Hash als Anzahl abbildet. Oder gibt es einen SQL-Befehl, der das zu tun in der Lage ist? Oder gibt es noch viel elegantere Lösungen?
Grübelnde Grüße
JOhnnY
-
Hi,
Meine Idee ist, eine Tabelle mit drei Spalten zu erstellen: Datum, Klicks und Forms.
solange sich die Anforderungen nicht verändern, reicht dies vermutlich aus.
Für die Übersicht erstelle ich ein Script (Perl), welches die gesamte Tabelle einliest, die gewünschte ID in den Feldern findet und in einem Hash als Anzahl abbildet.
Ich widerstehe soeben der Versuchung, einen unartikulierten Laut in Großbuchstaben zu notieren und mit extremst (sic) vielen Ausrufezeichen abzuschließen.
Oder gibt es einen SQL-Befehl, der das zu tun in der Lage ist?
Ja, er nennt sich WHERE-Klausel. Bist Du sicher, dass Du SQL zumindest buchstabieren kannst, wenn Du schon so fragst?
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hallo Cheatah,
Oder gibt es einen SQL-Befehl, der das zu tun in der Lage ist?
Ja, er nennt sich WHERE-Klausel. Bist Du sicher, dass Du SQL zumindest buchstabieren kannst, wenn Du schon so fragst?
--- hhhmmm. Ich habe mich wohl mißverständlich ausgedrückt. Oder ich habe krause Gedanken im Kopf. Mein Modell sieht quasi so aus:
Datum Klick Form
21.02.2010 3 3
1 1
2
5
3Das ist vielleicht blöd gedacht. Ich dachte, _eine_ Zeile für jedes Datum aufzumachen und da _alle_ IDs reinzuschreiben. Hier kann man mit WHERE meines Erachtens nicht die Anzahl der Klicks mit ID 3 herausfinden? Alternativ könnte man es mit einer neuen Zeile pro Aktion machen, dann ginge es natürlich:
Datum Klick Form
21.02.2010 3
21.02.2010 3
21.02.2010 1
21.02.2010 1
21.02.2010 2
21.02.2010 5
21.02.2010 3oder, wenn ich Encoder richtig verstanden habe, das Datum in die Felder und eine Zeile pro ID:
ID Klick Form
1 21.02.2010 21.02.2010
2 21.02.2010
3 21.02.2010 21.02.2010
21.02.2010
5 21.02.2010Ich frage mich, welche Art der Speicherung letztendlich am effektivsten, bzw. ressourcenschonendsten ist. Die Übersicht muß nur einmal am Tag aufgerufen werden, insofern kann das Extrahieren der Klicks und Forms für eine ID ruhig etwas 'teurer' werden.
Ich hoffe, es ist etwas klarer geworden, was ich meine?
Besten Gruß
JOhnnY-
Mahlzeit Johnny B.,
Ich frage mich, welche Art der Speicherung letztendlich am effektivsten, bzw. ressourcenschonendsten ist.
Die genügend normalisierte.
Ich würde eine entsprechende Tabelle ungefähr folgendermaßen aufbauen:
ID | Timestamp | Type | Key
----+---------------------+------+-------------
8 | 22.02.2010 16:11:05 | L | irgendwas
15 | 22.02.2010 16:37:07 | F | was_anderes
42 | 22.02.2010 17:23:52 | L | foobarDie Spalte "ID" ist dabei der Primärschlüssel der Tabelle (AUTO_INCREMENT), "Timestamp" ein entsprechend geeignetes Datumsformat, "Type" eine Enumeration aus
('F', 'L')(z.B. für "Form" und "Link") und "Key" ein passend dimensioniertes VARCHAR-Feld für die per URL oder Formular übergebenen "ID"s (deren Namen ich übrigens ungünstig gewählt finde).Für jeden aufgerufenen Link bzw. jedes verarbeitete Formular wird ein entsprechende (Log-)Eintrag erstellt.
Aggregieren kannst Du die dann zu beliebigenen Zeitpunkten auf beliebige Weise.
MfG,
EKKi--
sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|-
Hallo EKKi,
Die genügend normalisierte.
--- das habe ich neulich mit großem Interesse in einem mySQL-Buch gelesen (da ging es bis zur 3NF, dies würde ausreichen, hieß es). Wobei ich den Bezug auf meine Klickstatistik nicht sehe? Es gibt hier doch gar keine Abhängigkeiten?!
Die Spalte "ID" ist dabei der Primärschlüssel der Tabelle (AUTO_INCREMENT), "Timestamp" ein entsprechend geeignetes Datumsformat, "Type" eine Enumeration aus
('F', 'L')(z.B. für "Form" und "Link") und "Key" ein passend dimensioniertes VARCHAR-Feld für die per URL oder Formular übergebenen "ID"s (deren Namen ich übrigens ungünstig gewählt finde).--- jau, sehr schön. ID als Primärschlüssel wird letztendlich nie benutzt werden, wobei ich habe gelesen habe, man soll _immer_ einen unabhängigen Primärschlüssel verwenden. Der Namen für meine IDs ist in diesem Zusammenhang tatsächlich irreführend gewählt.
Für jeden aufgerufenen Link bzw. jedes verarbeitete Formular wird ein entsprechende (Log-)Eintrag erstellt.
--- dann entsteht durch meinen Gedanken, alle Klicks und Forms in eine Zeile zu schreiben, um Zeilen zu sparen, keinerlei Vorteil, sondern nur grausamer Datenmatsch?
Mille Grazie
JOhnnY-
Mahlzeit Johnny B.,
Wobei ich den Bezug auf meine Klickstatistik nicht sehe? Es gibt hier doch gar keine Abhängigkeiten?!
Das ist zugegebenermaßen richtig. Aber wenn man das immer im Hinterkopf behält, kommt man gar nicht erst auf die Idee, nicht-normalisierte Tabellen zu entwerfen ... :-)
dann entsteht durch meinen Gedanken, alle Klicks und Forms in eine Zeile zu schreiben, um Zeilen zu sparen, keinerlei Vorteil, sondern nur grausamer Datenmatsch?
*SO* hätte ich das zwar nicht formuliert - aber grob gesehen hast Du vollkommen recht.
MfG,
EKKi--
sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
-
-
Hallo EKKi,
Aggregieren kannst Du die dann zu beliebigenen Zeitpunkten auf beliebige Weise.
Jetzt würde ich denken bräuchte ich auf jeder Spalte einen Index. Id hat sowieso den Primary. Ich lasse nach Datum, nach Type und nach Key aggregieren. Aber macht eine Tabelle mit einem Index pro Spalte tatsächlich Sinn?
Besten Gruß
JOhnnY
-
-
Hi,
Ich frage mich, welche Art der Speicherung letztendlich am effektivsten, bzw. ressourcenschonendsten ist. Die Übersicht muß nur einmal am Tag aufgerufen werden, insofern kann das Extrahieren der Klicks und Forms für eine ID ruhig etwas 'teurer' werden.
Vom Datenmodell abgesehen darf dann auch die Wahl der Storage-Engine überdacht werden - bspw. die ARCHIVE-Engine könnte u.U. interessant sein für Vorhaben dieser oder ähnlicher Art.
MfG ChrisB
--
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]-
Hallo ChrisB,
Vom Datenmodell abgesehen darf dann auch die Wahl der Storage-Engine überdacht werden - bspw. die ARCHIVE-Engine könnte u.U. interessant sein für Vorhaben dieser oder ähnlicher Art.
--- ich habe nicht verstanden, wo der Vorteil liegt? Es heißt, Indizierung wird nicht unterstützt. Das macht doch die 'normale' Tabelle schneller - oder ist eine ARCHIVE-Engine sowieso viel schneller unterwegs?
JOhnnY
-
-
-
-
Hi,
sorry, nach nochmaligem Durchlesen:
Meine Idee ist, eine Tabelle mit drei Spalten zu erstellen: Datum, Klicks und Forms.
Du meinst diese Spalten doch sicher zusätzlich zur ID, oder? Ansonsten hättest Du nämlich ein Datenmodell, welches dem Nährwert eines durchschnittlichen BigMäc erschreckend nahe kommt.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Du meinst diese Spalten doch sicher zusätzlich zur ID, oder? Ansonsten hättest Du nämlich ein Datenmodell, welches dem Nährwert eines durchschnittlichen BigMäc erschreckend nahe kommt.
--- das sieht aber doch gar nicht so schlecht aus? ;-)
Big Mac® Zutaten, Nährwerte und Allergene
Zutaten: Weizenbrötchen mit Sesam bestreut, 100% Rinderhackfleisch, Zwiebeln, Salzgurkenscheiben, Eisbergsalat, Cheddar-Schmelzkäsezubereitung und Big Mac Sauce
Nährwerte: 100g Portion
Brennwert (kJ) 938 2073
Brennwert (kcal) 224 495
Eiweiß (g) 12 27
Kohlenhydrate (g) 18 40
davon Zucker (g) 4 8
Fett (g) 11 25
davon gesättigte
Fettsäuren (g) 5 10
Ballaststoffe (g) 1 3
Kochsalz (g) 1,0 2,3
Allergene:
Glutenhaltiges
Getreide 1) Ja
Krebstiere Nein
Eier Ja
Fisch Nein
Erdnüsse Nein
Soja Ja
Milch (einschl.
Lactose) Ja
Schalenfrüchte 2) Nein
Sellerie Nein
Senf Ja
Sesamsamen Ja
Schwefeldioxid,
Sulfite Nein
Lupinen Nein
Weichtiere Nein
-
-
Meine Idee ist, eine Tabelle mit drei Spalten zu erstellen: Datum, Klicks und Forms. Bei jedem Klick wird die mitgesandte ID in das Feld 'Klicks' geschrieben. Entsprechend wird bei jedem Formular die ID in das Feld 'Forms' geschrieben.
Dann ist aber immer ein Feld leer? Ich würd lieber ein Feld "ID" machen und eines in dem der Typ der ID drin steht.
Das sind zwar auch drei Felder, aber diesen Aufbau finde ich schöner als wenn man auf Feld IS NOT NULL abfragen muss.