【问题标题】:Storing IPv4 & IPv6 in an RDBMS (MySQL)在 RDBMS (MySQL) 中存储 IPv4 和 IPv6
【发布时间】:2011-08-30 08:43:24
【问题描述】:

我在这里看到了许多关于在 RDBMS 中存储 IPv4 和 IPv6 地址的问题(并已阅读)(通常是 MySQL,与我的情况不同 em>)

无论如何,如果(而且我的阅读方式也不同,因此请告知这是否不正确或已正式弃用)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 范围内就像 IS NULL 一样简单。

但是,我看到VARBINARY(16) 出现在许多解决方案中。

VARBINARY(16) 或2 个未签名的BIGINT 列上实施此解决方案是否有任何可预见的性能增益/损失?关于索引,或任何进一步的考虑?

【问题讨论】:

    标签: mysql ipv6 binary-data ipv4


    【解决方案1】:

    恕我直言,将数据分成两列是最糟糕的设计,我要么

    • 使用两个单独的字段,每个字段的长度足以容纳整个值,填充相应的字段并将另一个字段设置为 NULL;
    • 使用一个字段存储数据(足够长以保存最长的可能值)和另一个字段存储数据类型(ipv4 或 ipv6);

    哪个“更好”取决于您如何使用数据。仅当您的空间非常紧张时,才在两列之间拆分值才有意义,而现在通常情况并非如此。

    【讨论】:

    • 谢谢@ain - 我明白你的意思了。我从与物理地址相同的角度来看它,至少就规范化而言。数据的用例(至少在这种情况下)是一个活动日志,并且 IP 禁止,呃,读取和写入(基本上每个请求都会发出读取,大多数requests 将发出 write)所以您的答案本质上是 VARBINARY(16) 解决方案(或至少在同一方面)再次感谢,我会考虑您的观点;希望我能在这个问题上得到很好的意见。
    猜你喜欢
    • 2011-07-19
    • 1970-01-01
    • 2012-05-22
    • 2016-09-18
    • 2013-07-03
    • 2014-05-03
    • 1970-01-01
    • 2022-08-21
    • 2018-07-27
    相关资源
    最近更新 更多