IP-Sperre Datenstrukturdiskussion (wenn schon, dann richtig)

[Philipp Hasenfratz]

Halihallo thematrixhasyou

if ($option) {
 ## Alle IP´s löschen, die älter als 24 Stunden

Warum das Usertracking über 24 Stunden bei IP's wenig Sinn macht und mit hohen
Fehlerraten verbunden ist, steht ausführlich im </archiv/>.

Der nächste Abschnitt ist eigentlich unnötig *g* . Aber irgendwie hatte er

Sinn, weiss auch nicht mehr so richtig. Bei irgendjemandem kam es vor,

dass 2 Einträge mit der gleichen IP waren. deswegen das doppelt gemoppelte.

Es kann sogar sein, dass 10'000 Computer dieselbe IP zur selben Zeit "haben". Oder aber,
dass ein Computer innerhalb von 24 Stunden 10 IP's hat. _Das_ ist das Problem.

if ($num) {
echo "Hey, Hansl. Nur ein Vote innerhalb 24 Stunden. Oder ein anderer von ca. 10'000,

welche dieselbe IP haben...";

Da anscheinend sehr oft derartige IP-Sperren realisiert werden (über deren Sinn und
Unsinn schon sehr oft im Archiv diskutiert wurde), hier noch einige Anmerkungen, wie man
die Datenstruktur etwas effizienter aufbaut:

}
CREATE TABLE countertemp (
 id int(5) NOT NULL AUTO_INCREMENT,

Wenn schon INT und derart grosse Anzahlen an Einträgen, dann bitte INT(10), denn jede
Zahl, die über INT abgebildet werden kann, hat auch in 10 Stellen platz, nicht so in 5.

timestamp int(15) default NULL,

Eine Timestamp soll _immer_ in einem SMALLINT(5) UNSIGNED gespeichert werden! - Alles
andere ist Platzverschwendung. Möglich wäre auch DATETIME, obwohl ein SMALLINT(5) für
diese Anwendung wohl effizienter zu handhaben ist.

IP varchar(20) default NULL,

IP's haben maximal 15 Zeichen, also wenn, dann VARCHAR(15). Zudem halte ich hier VARCHAR
für eine Platz und Performanceverschwendung, besser wäre CHAR(15), da diese direkt in die
RecordData geschrieben wird und nicht extra variabler Platz dafür reserviert werden muss.
Zudem: Das Selektieren geht tausendmal schneller.

vote\_id int(5) default NULL,

Gibt's echt bis zu 2^64 Votes? - Schön für dich, alles andere ist Platzverschwendung.
Verwende MEDIUM- oder SMALLINT.

Und wo, wo bitte sind die Indizies, welche die Abfragen derart verschnellern könnten? -
Das ist essenziell für diese Aufgabe!

http://www.mysql.com/doc/en/MySQL_indexes.html

Also, Index auf DATETIME, Index auf IP, Index auf vote_id.

Wenn man schon derart performancesensitiven Programme schreibt (bei jedem Zugriff in
mehreren tausend IP's sehen, ob der User schon gevoted hat), sollte man sich schon etwas
mehr Gedanken zur Datenstruktur (die Programmierung lasse ich jetzt mal weg) machen.

Desweiteren macht ID als Primary Key hier keinen Sinn. PRIMARY KEY (timestamp,IP) wäre
wesentlich intelligenter, da a) der Index dann schon implizit ist, b) kein Platz für
Index und Daten der ID verbraucht wird und c) sowieso nur auf timestamp und IP selektiert
wird und somit ID völlig nutzlos ist. Dass dann keine zwei Records zur gleichen timestamp
und IP gespeichert werden können ist klar, aber was wäre denn der Vorteil davon? - Also:
PRIMARY KEY ist timestamp und IP.

Meine positive Kritik zur Datenstuktur einer IP-Sperre.

Viele Grüsse

Philipp