Ich möchte einen benutzerorientierten Ansichtszähler implementieren (ähnlich dem, was SO für Frageansichten hat), der die Anzahl der eindeutigen Ansichten einer Seite verfolgt. Es gibt ein paar ähnliche Fragen hier, aber keine scheint meine Frage vollständig zu beantworten .
Was wäre das beste Setup dafür (in Bezug auf Datenbanktabellen usw.)? Wäre es gut, der Tabelle "Fragen" eine Spalte "Ansichten" hinzuzufügen und diese bei jeder Seitenansicht einfach zu erhöhen? Und wenn ich möchte, dass die Ansichten eindeutig sind, könnte ich eine andere Tabelle mit Frage-IDs und IP-Adressen haben und die "Ansicht" -Spalte nur erhöhen, wenn es nicht schon einen Eintrag mit der aktuellen IP-Adresse gibt. Allerdings würde diese 'ip-view'-Tabelle sehr schnell enorm werden ... Hauptsächlich geht es mir um den Aufwand, jede Seite und jede IP in einer Tabelle speichern zu müssen.
Wie könnte dies optimiert werden, damit es nicht zu einem Leistungsengpass wird? Gibt es einen besseren Ansatz als das, was ich beschrieben habe? Bitte beachten Sie, dass es für mich sehr wichtig ist, dass nur einmalige Ansichten gezählt werden.
Update : Zusätzlich zu den Implementierungsmethoden möchte ich auch weiter verstehen, wo die Performance-Probleme ins Spiel kommen, wenn man den naiven Ansatz betrachtet, einfach zu überprüfen, ob die IP existiert und die Ansicht zu aktualisieren 'Spalte auf jeder Seitenansicht. Das Hauptproblem ist eine große Anzahl von Einfügungen (unter der Annahme starken Datenverkehrs) oder eher die Größe der Objekt-zu-IP-Zuordnungstabelle (die sehr groß sein kann, da für jeden neuen eindeutigen Besucher eine neue Zeile pro Frage eingefügt wird). Sollten Race-Bedingungen in Betracht gezogen werden (ich nahm einfach an, dass eine update / increment SQL-Anweisung atomar war)? Sorry für alle Fragen, aber ich bin nur verloren, wie ich das angehen sollte.
Wenn Sie eindeutige Sichten spezifisch verfolgen müssen, gibt es wahrscheinlich zwei Möglichkeiten, dies zu tun ... es sei denn, Sie arbeiten mit internen Benutzern, die Sie identifizieren können. Um dies zu tun, müssen Sie nun jeden Benutzer im Auge behalten, der die Seite besucht hat.
Die Verfolgung kann entweder serverseitig oder clientseitig erfolgen.
Serverseitig müssen IP-Adressen sein, es sei denn, Sie haben mit internen Benutzern zu tun, die Sie identifizieren können. Und immer, wenn Sie mit IP-Adressen arbeiten, treffen Sie alle üblichen Vorbehalte, wenn es darum geht, sie zur Identifizierung von Personen zu verwenden (es könnte mehrere Benutzer pro IP oder mehrere IPs pro Benutzer geben), und Sie können nichts dagegen tun.
Sie sollten auch bedenken, dass die "riesige IP-Tabelle des Todes" nicht so schlecht von einer Lösung ist. Leistung wird nur dann ein Problem, wenn Sie Hunderttausende von Benutzern haben ... natürlich vorausgesetzt, dass es richtig indiziert ist.
Client-Seite bedeutet wahrscheinlich, dass Sie ein "Ich habe besucht!" Plätzchen. Wenn der Cookie NICHT vorhanden ist, erhöhen Sie Ihre Benutzeranzahl. Wenn der Cookie nicht erstellt werden kann, müssen Sie mit einer überhöhten Benutzeransicht leben. Und all die Vorbehalte gegen den Umgang mit Cookies gelten ... das heißt, sie werden irgendwann schlecht werden und verschwinden.
Es scheint einen revolutionären Ansatz zu geben (von Kopf bis Fuß), von dem ich selbst noch nicht sicher bin, ob er skalierbar oder eher machbar ist.
Wenn Sie die IP wirklich in DB speichern wollen und vermeiden möchten, dass Ihre DB verstopft wird, sollten Sie sie in einer hierarchischen Reihenfolge speichern.
%Vor%Wenn ein Benutzer also Ihre Website von IP 212.121.139.54 aus besucht, lauten die Zeilen in der Tabelle:
& lt; 1, 212, 1, 0, 0 & gt; & lt; 2, 121, 2, 1, 0 & gt; & lt; 3, 139, 3, 2, 0 & gt; & lt; 4, 54, 4, 3, 1 & gt;
Zu beachtende Punkte:
Also, chao, lass mich wissen, was hast du implementiert?
Tags und Links php design database-design