存储 IPv4 和 IPv4 RDBMS (MySQL) 中的 IPv6
我在这里看到了许多关于在 RDBMS 中存储 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 范围内就像 IS NULL 一样简单。
但是，我在许多解决方案中都看到了 VARBINARY(16) 。
通过 VARBINARY(16) 或 2 个无符号 BIGINT 列实施此解决方案是否会带来任何可预见的性能增益/损失？索引怎么样，或者还有其他考虑因素吗？
I've seen a number of questions floating around here (and have read them) regarding storing both IPv4 and IPv6 addresses in an RDBMS (typically MySQL, not unlike my case)
Anyways, if (and I've read differently too, so advise if this is incorrect or officially deprecated) IPv4 address are zero-padded and stored in the ::/96 block in translation, would it make sense to use two columns, perhaps:
`ip96` BINARY(12) NULL , /* first 3 bytes of ipv6 */
`ip32` BINARY(4) NOT NULL , /* whole ipv4 or last byte of ipv6 */
This makes sense in my head as far as data normalization goes, and testing whether an address is in the IPv4 or IPv6 range is as easy as IS NULL.
However, I've seen VARBINARY(16) thrown around in a number of solutions.
Are there any foreseeable performance gains/losses from implementing this solution over VARBINARY(16) or 2 unsigned BIGINT columns? What about indexing, or any further considerations?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
恕我直言，将数据拆分为两列是最糟糕的设计，我要么
哪一个“更好”取决于您如何使用数据。仅当空间非常紧张时，将值拆分在两列之间才有意义，但现在通常情况并非如此。
IMHO splitting data to two columns is worst design, I would either
Which one is "better" depends on how you use the data. Splitting the value between two columns only makes sense when youre really tight on space, which usually isn't the case nowadays.