Spara definitivt IP-adresser som siffror, om du inte har något emot det extra arbete som krävs, speciellt om du behöver göra frågor om adresserna och du har stora tabeller/samlingar.
Här är anledningen:
Lagring
- En IPv4-adress är 4 byte om den lagras som heltal utan tecken.
- En IPv4-adress varierar mellan 10 byte och 18 byte när den skrivs ut som en sträng i prickad okted form. (Låt oss anta att genomsnittet är 14 byte.)
Det är 7-15 byte för tecknen, plus 2-3 byte om du använder en strängtyp med variabel längd, som varierar beroende på vilken databas du använder. Om du har en strängrepresentation med fast längd tillgänglig måste du använda ett fält med fast bredd på 15 tecken.
Disklagring är billig, så det är inte en faktor i de flesta användningsfall. Minne är dock inte lika billigt och om du har en stor tabell/samling och du vill göra snabba frågor behöver du ett index. 2-3x lagringsstraffet för strängkodning minskar drastiskt mängden poster du kan indexera samtidigt som indexet behålls i minnet.
- En IPv6-adress är 16 byte om den lagras som ett heltal utan tecken. (Antagligen som flera 4 eller 8 byte heltal, beroende på din plattform.)
- En IPv6-adress sträcker sig från 6 byte till 42 byte när den kodas som en sträng i förkortad hex-notation.
I den nedre delen är en bakåtslingaadress (::1) 3 byte plus strängen med variabel längd. I den avancerade delen, en adress som 2002:4559:1FE2:1FE2:4559:1FE2:4559:1FE2 använder 39 byte plus strängen med variabel längd.
Till skillnad från med IPv4 är det inte säkert att anta att den genomsnittliga IPv6-stränglängden är medelvärdet 6 och 42, eftersom antalet adresser med ett betydande antal på varandra följande nollor är en mycket liten del av det totala IPv6-adressutrymmet. Endast vissa speciella adresser, som loopback- och autoconf-adresser, kommer sannolikt att vara komprimerbara på detta sätt.
Återigen, detta är en lagringsavgift på>2x för strängkodning kontra heltalskodning.
Network Math
Tror du att routrar lagrar IP-adresser som strängar? Naturligtvis gör de inte det.
Om du behöver göra nätverksmate på IP-adresser är strängrepresentationen ett krångel. T.ex. om du vill skriva en fråga som söker efter alla adresser på ett specifikt subnät ("returnera alla poster med en IP-adress i 10.7.200.104/27", kan du enkelt göra detta genom att maskera en heltalsadress med en heltalssubnätmask. ( Mongo stöder inte just den här frågan, men de flesta RDBMS gör det.) Om du lagrar adresser som strängar måste din fråga konvertera varje rad till ett heltal och sedan maskera den, vilket är flera storleksordningar långsammare. (Bitvis maskering för en IPv4-adress kan göras i några få CPU-cykler med hjälp av 2 register. Att konvertera en sträng till ett heltal kräver en loop över strängen.)
På liknande sätt kommer intervallfrågor ("retur all records all records between 192.168.1.50 and 192.168.50.100") med heltalsadresser att kunna använda index, medan intervallfrågor på strängadresser inte gör det.
Slutet
Det kräver lite mer arbete, men inte mycket (det finns en miljon aton()- och ntoa()-funktioner där ute), men om du bygger något seriöst och solidt och du vill framtidssäkra det mot framtida krav och möjligheten till en stor datauppsättning bör du lagra IP-adresser som heltal, inte strängar.
Om du gör något snabbt och smutsigt och inte har något emot möjligheten att göra om i framtiden, använd sedan snören.
För OP:s syfte, om du optimerar för hastighet och utrymme och du inte tror att du vill fråga det ofta, varför använda en databas överhuvudtaget? Skriv bara ut IP-adresser till en fil. Det skulle vara snabbare och mer lagringseffektivt än att lagra det i en databas (med tillhörande API och lagringskostnader).