Za IP adresu ne postoji poseban tip za skladištenje, na nju (najčešće) gledaš kao običan string, bilo u domain ili database logici, tako da bi npr. ta kolona u kojoj hoćeš da čuvaš IP adrese mogla da bude tipa VARCHAR(100).

Zapravo je int najpogodniji za cuvanje IP adrese jer je najmanji u koji IP adresa moze da se upise, te s njim ne pravis nepotrebno zauzimanje prostora.

a šta mislite dali je bolje vako da spremim

`IP` tinytext NOT NULL,

vako se u smf foruma sprema ip adresa korisnika


i još jedno pitanje

kako da spremim hos od korisnika (npr: 78-3-51-116.adsl.net.t-com.hr) ?

`ip` INT(10) unsigned DEFAULT 0


upis u bazu: INSERT INTO ... VALUES ( INET_ATON('$ipaddr'), ...)

ispis iz baze: SELECT INET_NTOA(`ip`) AS `ipaddr`

afwt ti je dobro napisao, koristi INT kao tip podatka i MySQL-ovu funkciju INET_ATON.
A vezano za hostname, ja bih to prebacio najprije u IP adresu pa onda tek upisao u bazu.

ja sam koristio varchar 12 (upis bez tačaka).
Ne znam za šta ti je potrebno i ime hosta, moraš da računaš na to da ti ponekad treba dosta vremena za njegovo razrešenje.
Ja sam IP koristio za kontrolu zapisa (ukoliko neko ima previše naloga za oglase a dolaze sa iste adrese...)

@agvozden: Ne valja ti to resenje, neispravno je. :( Tako onda ne mozes da razlikujes IP adresu 12.123.12.123 od 121.23.12.123.

Ne kapiram cemu cela prica sa textom (varchar-om). IP jeste integer, 32-bitni integer za IP v4. Podela na oktete i zapis sa tackama izmedju je samo da bi se lakse citalo/pamtilo, podatak je cist int.

Ne ukoliko koristi početne nule, npr. 12.123.12.123 -> 0121230123123. Mada se meni više sviđa INET_ATON funkcija, prvi put je vidim i baš mi je zapala za oko.

Al' dobro opet sve zavisi u koje svrhe će da koristi tu IP adresu. Ako mu bude trebala za neke proračune, onda se kao logično rešenje nameće INT sa prethodnom obradom koristeći INET_ATON(). Ja sam iz njegovog post-a shvatio da je u pitanju neka aplikacija, gde bi se IP adresa koristila u svrhe običnog output-a, ili eventualno provere SPAM-a, ako su u pitanju korisnički komentari ili nešto slično, a u tom slučaju, ne vidim zašto se za tako nešto ne bi koristio neki VARCHAR...

ne postoji nikakav razlog da se ip cuva kao varchar osim neznanje

ako hoce da cuva hostname - to je druga prica

@afwt

Naprotiv, kao što reče burex koristim vodeće nule, tako da prostim pregledom baze mogu zapisi lako da se uporede.

Ali, ne tvrdim da je to najbolje rešenje, bilo je iznuđeno, da sam radio ovo u fazi projektovanja razmislio bih o upotrebi int-a.

Lagano počinjem da razmišljam i o varijantama za ipv6...

Obavezno IP cuvati kao int i to unsigned int jer ce vracati nepravilne rezultate ako tip int nije definisan kao iskljucivo pozitivan.
Za razliku od MySQL-a, PostgeSQL ima tip podataka koji se bavi iskljucivo IP adresama i to ne samo IPv4 vec i IPv6 i CIDR... (http://www.postgresql.org/docs/8.2/static/datatype-net-types.html).

yup pgsql je mnogo napredniji kod tih "ne-standardnih db stvari" ... manipulacija ip-om je jedna od njih, gis je druga .. (i koliko ja mogu da vidim "iznutra" po tom pitanju se nista nece promeniti, nadam se da gresim)...

sto se tice ipv6 .. najmanji integer koji moze da sacuva 6 bajtni broj je na zalost bigint (koji je 8 bajtova). teoretski bi mogao da se koristi char(6) sa binarnom kolacijom ali bi to bilo prilicno "smaranje" za implementaciju ..