Sql Server 2008 的 4 字节无符号整数？
我知道关于这个问题有很多问题，但我还没有找到“是的，这就是如何......”的明确答案，
所以这里又是：存储无符号整数值（32-位值或 32 位位图）转换为 SQL Server 中的 4 字节字段？
以下是我看到的想法：
1）对所有值使用 -1*2^31 偏移量
- 缺点：需要在读/写/聚合之前对值执行数学运算。
2）使用4个tinyint字段
- 缺点：需要连接值来执行任何操作
3）使用binary（4）
- 缺点：实际上使用4 + 2字节的空间（编辑：varbinary（4）使用4 + 2，binary（ 4) 仅使用 4)
- 需要在 SqlBinary 中工作或与其他类型进行转换
I understand there are multiple questions about this on SO, but I have yet to find a definitive answer of "yes, here's how..."
So here it is again: What are the possible ways to store an unsigned integer value (32-bit value or 32-bit bitmap) into a 4-byte field in SQL Server?
Here are ideas I have seen:
1) Use a -1*2^31 offset for all values
- Disadvantages: need to perform math on the values before reading/writing/aggregating.
2) Use 4 tinyint fields
- Disadvantages: need to concatenate values to perform any operations
3) Use binary(4)
- Disadvantages: actually uses 4 + 2 bytes of space (Edit: varbinary(4) uses 4+2, binary(4) only uses 4)
- Need to work in SqlBinary or cast to/from other types
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
IMO，您有在 4 个字节中存储 2^32 个正值的正确答案：要么是标准
int并进行数学运算，要么是binary(4)，相反按照你所说的，只会消耗4个字节的空间。 （只有varbinary会产生额外的 2 个字节的存储空间）。在我看来，一系列tinyint或smallint列会非常麻烦。当然，还有另一种存储 2^32 正值的解决方案，但它需要八个字节：带有检查约束的 bigint。考虑到当今的存储和内存是多么便宜，IMO，考虑到您必须跳过其他解决方案的编程循环，这是最简单和最便宜的解决方案，但显然您有理由想要在每行上保存额外的 4 个字节。
IMO, you have the correct answers to storing 2^32 positive values in 4 bytes: either a standard
intand you do the math or abinary(4)which, contrary to what you have said, will only consume 4 bytes of space. (Onlyvarbinarywill incur an extra 2 bytes of storage). A series oftinyintorsmallintcolumns would be unjustifiably cumbersome IMO.Of course there is another solution for storing 2^32 positive values but it takes eight bytes: a bigint with a check constraint. Given how cheap storage and memory is today, IMO, this is the simplest and cheapest solution given the programmatic hoops you will have to jump through with the other solutions, however clearly you have a reason for wanting to save the extra 4 bytes on each row.