Datentyp für IP-Adresse

[dcst55]

Hallo zusammen,
ich habe in einer Spalte IP-Adressen. Der Datentyp ist aktuell varchar(32).
Kann ich Vorteile erwarten, wenn ich die IP-Adressen als int und per INET_ATON ablege?
Ich erhoffe mir dabei Performancesteigerungen bei der Abfrage.
hat jemand Erfahrungen damit gesammelt?

 

[akretschmer]

kommt drauf an, was Du machen willst. Richtig clever wäre ein Datentyp, der solche Daten RICHTIG erkennen, indexieren & verarbeiten kann, der z.B. dies richtig macht:

postgres=# select '192.168.001.001'::inet = '192.168.1.1'::inet;
 ?column? 
----------
 t
(1 row)

Aber das kann MySQL meines Wissens nach nicht.

8.9. Network Address Types

8.9. Network Address Types 8.9.1. inet 8.9.2. cidr 8.9.3. inet vs. cidr 8.9.4. macaddr 8.9.5. macaddr8 PostgreSQL offers data types to …

www.postgresql.org

 

[Walter]

Kann ich Vorteile erwarten, wenn ich die IP-Adressen als int und per INET_ATON ablege?

Der Index für einen INT ist vermutlich kleiner und bei einer genauen Abfrage auch schneller.

Andererseits musst Du dann zB Abfragen wie "ipadresse LIKE '192.168.10.%';" umschreiben als ipadresse BETWEEN INET_ATON('192.168.10.0') AND INET_ATON('192.168.10.255');.

 

[dabadepdu]

Andererseits musst Du dann zB Abfragen wie "ipadresse LIKE '192.168.10.%';" umschreiben

Das finde ich ja noch relativ harmlos. Und es ist sogar sauber.
Was ist mit 192.168.10.% versus 192.168.010.% usw. oder mit 912.168.10.%?
Ich weiß nicht, wie sich die Funktion genau verhält. Eine Stichprobe ergibt, dass sie für ungültige IP NULL zurück gibt. Da würde ich sagen, mal wieder typisch mySQL. Wie unterscheidet man eine falsche IP von einer fehlenden?

 

[akretschmer]

Eine Stichprobe ergibt, dass sie für ungültige IP NULL zurück gibt.

ja, korrekt wäre ein Fehler wie hier:

postgres=# select '192.168.1.1'::inet;
    inet     
-------------
 192.168.1.1
(1 row)

postgres=# select '292.168.1.1'::inet;
ERROR:  invalid input syntax for type inet: "292.168.1.1"
LINE 1: select '292.168.1.1'::inet;
               ^
postgres=#

MySQL halt ...

 

[dabadepdu]

ja, korrekt wäre ein Fehler wie hier:

Jein, ich wette, die Dokumentation zu der Funktion, behauptet nichts anderes als das was sie macht. Insofern kann man nicht von Fehler sprechen oder? Ich meine Du hast bei postgres eine Typisierung genutzt, INET_ATON von mySQL ist aber eine Funktion.
Das ist schon mal besser als nichts, leider nur einfach nicht ohne eine Extraschleife zu gebrauchen.

 

[akretschmer]

Jein, ich wette, die Dokumentation zu der Funktion, behauptet nichts anderes als das was sie macht. Insofern kann man nicht von Fehler sprechen oder?

wenn ich eine Funktion mit ungültigen Parametern aufrufe, sollte sie also ein zufälliges Ergebniss (hier: NULL) liefern?

 

[dabadepdu]

wenn ich eine Funktion mit ungültigen Parametern aufrufe, sollte sie also ein zufälliges Ergebniss (hier: NULL) liefern?

Nein, ich sehe es ja im Prinzip wie Du, es ist ärgerlich und wenn man es sicher/richtig machen möchte, muss man wieder extra rumwursteln.
Ich meine nur (hab nicht nachgeschaut), dass die Doku zur Funktion bestimmt einen Hinweis zu diesem schrägen Verhalten bringt. Damit "funktioniert" sie formal. Man kann sich sogar drauf berufen, "tut, was sie soll", dokumentiertes Verhalten, blabla.
Und klar, niemand hätte oracle daran gehindert, es richtig zu machen, aber die brauchen offenbar immer so Argumente, um ihre Hausmarke zu teuer zu verkaufen.
Und immer wenn ich von den merkwürdigen Effekten in der Wahrenwirtschaft eines Bekannten höre, dann kann ich nicht anders, als an diese DB zu denken.

 

[dcst55]

Der Einwand ist nicht unberechtigt. Ich habe es mal geprüft. Das Verhalten von MariaDB ist das selbe. Aber für uns vollkommen ok, da ja auch bekannt. Tippfehler können wir in erster Linie auch ausschließen, da die IP-Adressen per Skript abgegriffen und in die Datenbank geschrieben werden. und da die Spalte NOT NULL ist, erhalten wir spätestens beim schreiben des Datensatzes einen Fehler...

Das finde ich ja noch relativ harmlos. Und es ist sogar sauber.
Was ist mit 192.168.10.% versus 192.168.010.% usw. oder mit 912.168.10.%?
Ich weiß nicht, wie sich die Funktion genau verhält. Eine Stichprobe ergibt, dass sie für ungültige IP NULL zurück gibt. Da würde ich sagen, mal wieder typisch mySQL. Wie unterscheidet man eine falsche IP von einer fehlenden?

 

[BerndB]

Also nur mal kurz!!
Es ist in jedem Fall sinnvoll eine IP V4 als UNSIGNED INT zu speichern, denn es ist nichts anders als 4 Byte auf Netzwerkebene.
Als String wird man NIE glücklich, denn "192.168.2.1" ist das gleiche wie "192.168.002.001". Was glaub ihr wie gut ein String vergleich da funktioniert.
Weiterhin sind solche Sachen wie "192.168.2.%" keine IP sonder nur eine Notation für einen IP Bereich und müssen dann auch
so behandelt werden. Das ganze lässt sich ja auch noch mit der Netzmaske verbinden wie "192.168.2.1/32" oder sogar
per Name wie "google.de", was auch eine IP repräsentiert.
Also, erst normalisieren und dann speichern

Als UNSIGNED INTEGER mit index ist das schnellste und sparsamste an Ressourcen

 

[akretschmer]

Als UNSIGNED INTEGER mit index ist das schnellste und sparsamste an Ressourcen

Völlig korrekt - solange man halt nichts besseres wie spezielle Datentypen für sowas hat.