Хранение IPv4 и IPv6 в РСУБД (MySQL) - PullRequest
Новая
       23

Хранение IPv4 и IPv6 в РСУБД (MySQL)

1 голос
/ 30 августа 2011

Я видел ряд вопросов ( и прочитал их ), касающихся хранения адресов IPv4 и IPv6 в СУБД (, как правило, MySQL, в отличие от моего случая )

В любом случае, если ( и я тоже читал по-разному, поэтому сообщите, если это неверно или официально устарели ) IPv4-адреса дополняются нулями и хранятся в блоке ::/96 вперевод, имеет ли смысл использовать два столбца, возможно: 

`ip96` BINARY(12) NULL ,     /* first 3 bytes of ipv6 */
`ip32` BINARY(4) NOT NULL ,  /* whole ipv4 or last byte of ipv6 */

Это имеет смысл в моей голове, насколько нормализация данных идет, и тестирование, находится ли адрес в диапазоне IPv4 или IPv6, так же простоas IS NULL.

Тем не менее, я видел VARBINARY(16) в ряде решений.

Существуют ли какие-либо ожидаемые приросты / потери производительности от внедрения этого решения в течение VARBINARY(16)или 2 беззнаковых BIGINT столбца?Как насчет индексации или каких-либо других соображений?

1 Ответ

1 голос
/ 30 августа 2011

ИМХО разделение данных на два столбца - худший дизайн, я бы либо

  • использовать два отдельных поля, каждое достаточно длинное, чтобы вместить все значение, заполнить соответствующее поле и установить другое в NULL;
  • использовать одно поле для данных (достаточно длинное, чтобы вместить самое длинное из возможных значений) и другое поле для хранения типа данных (ipv4 или ipv6);

Какой из них «лучше», зависит от того, как вы используете данные. Разделение значения между двумя столбцами имеет смысл только тогда, когда вы действительно ограничены в пространстве, что обычно не имеет места в настоящее время.

...