Как я определял провайдера по IP

[ToSHiC]

В таблице лучше хранить не начала и концы диапазонов, а блоки netnum/netmask, если диапазон нужно выразить несколькими такими блоками — то разбивать (но, обычно, адреса и выдают блоками). Поиск делать по ip & netmask == netnum, и сортировать по убыванию по количеству бит в netmask. Такую структуру можно вообще без базы данных создать, в виде префиксного дерева — будет работать очень быстро. Но даже в вашей схеме можно было бы использовать функцию INET_ATON(), чтобы запрос выглядел опрятнее.

В вашем варианте сортировка может работать не совсем правильно, при одинаковых sip надо искать наименьший eip.

И ещё момент, у вас в примере запроса sip и eip сравниваются с разными адресами — вы что-то хотели этим проиллюстрировать, или опечатка?

[vitalykhy]

Про сортировку вы правы, так же как и про разный ip. Это были опечатки — исправил. Спасибо.

[zelenin]

кажется статья о том, как вы скачивали архив и дамп загоняли в БД, но не об определении провайдера по IP.

[vitalykhy]

Не согласен с вами. В статье рассказан опыт получения, создания БД по провайдерам, а также вывод провайдера по ip адресу клиента в виде запроса.

[ExH]

Ripe, это не весь интернет.

Проще всего воспользоваться готовой базой от maxmind:
dev.maxmind.com/geoip/geoip2/geolite2-asn-csv-database

Кроме ipv4 ещё бывают ipv6.
Выше вам указали на INET_ATON, для ipv6 надо использовать INET6_ATON.

p.s. Мой ipv6 адрес от домашнего провайдера:
2a00:1c78:1:1e95:1114:6cd:600a:111

[vitalykhy]

Ripe, это не весь интернет.

да, вы правы.

Кроме ipv4 ещё бывают ipv6.

в ripe они есть, но в статье не рассмотрены

Проще всего воспользоваться готовой базой от maxmind:
dev.maxmind.com/geoip/geoip2/geolite2-asn-csv-database

бесплатная версия же урезана. А полная версия только за деньги.

[kornix]

Возможно, но в исходных условиях было сказано «IP -> Country Code». Для этого достаточно и урезанной версии. Далее, с учетом того, что анонсы более специфичные, чем /24, фильтруются, можно считать, что все адреса из блока /24 с вероятностью приближающейся к 1 будут иметь один Country Code (и один Organization Id), соответственно, и проверку можно значительно ускорить / упростить за счет другой структуры таблицы в БД.

Касательно взаимосвязи между объектами в RIPEdb: www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/rpsl-object-types

[bosom]

В базе, сделано верно, надо хранить именно диапазон, начало и конец в виде чисел (не слушайте глупости других комментаторов).
Когда потребуется повысить скорость поиска, то сможете выкинуть SQL и перейти на более быструю базу в которой по sip, eip построить базу с BTREE индексами, они отлично ложатся именно на диапазон.
Тогда поиск станет моментальным, а скорость ответа возрастёт минимум в 100 раз.
Как пример, решение с бд в 40 миллионов записей (все провайдеры мира), база данных Tarantool, язык golang.
Скорость нахождения ответа через api (REST/JSON) — 1.8мс-2мс. То есть, фактически все реальные затраты это кодирование/декодирование json + tcp/ip конекты. :)

Кстати, по некоторым табличкам не хватает индексов, а они сильно влияют на скорость поиска в SQL!

Ну а по теме самой статьи и её сути, могу сказать только то что мельчает хабр, ежегодный постоянный регресс. И это печально… Целая статья о скачивании и заливке базы в бд :(
Грустно это.

[php7]

Нужно больше таких статей.