IPv6 ist dabei nicht beachtet!

Was natürlich auch daran liegt, dass man in der Datenbank einen ganz anderen Spaltentyp braucht, IPv4 belegt 32 bit (4 Byte), IPv6 aber schon 128 bit (16 Bytes).

Afaik hat MySQL dafür noch keinen eigenen Spaltentyp, was meiner Meinung nach sinnvoll wäre, aber so oder so wird bei solch immensen "IP-Speicherungen" wie im Klickbereich/Reload einiges an "Platzverschwendung" durch IPv6 auf die Webbis zukommen.

Im Klickbereich kann man es noch so lösen, dass man in der Reloadtabelle nur ne ID ablegt (bei bis zu 65k Adressen reicht dann ja sogar ein smallint), und in einer anderen Tabelle die dazugehörige IP(v6) Adresse.

Für die Bettelreloads könnte das aber auch weniger optimal sein, da hier potentiell ja sehr viele verschiedene Adressen auftauchen, hm

Meiner Meinung nach sind die IPv6 Adressen absoluter overkill und IPv4 inkl. NAT hätte locker fürs I-Net an sich ausgereicht, wurde nur künstlich verknappt, und schließlich braucht demnächst ja jede Steckdose ihre eigene IP

Evtl. missfällt der ver-4-fachte Speicherverbraucht auch noch den ISPs auf, und sie einigen sich darauf, den "Kunden" erstmal nur bestimmte Teiladressbereiche zuzuweisen (was dann sofern es nur 64 bit betrifft, auch noch die nächsten 1.000 Jahre vermutlich reicht), dann kann man das auf BIGINT UNSIGNED abbilden. Oder es gibt so eine Möglichkeit schon, hab dazu aber aktuell noch nichts gefunden.