为什么SQL Server不支持无符号数据类型？

83

我专门在考虑未签名int。

这是一个实际的示例：当您的身份列超出限制时该怎么办？可以BigInt（存储8个字节而不是4个字节）或重构应用程序以支持负整数，甚至可以按照此答案创建自己的规则；这些选项都不是最佳选择。

UInt 会是一个理想的解决方案，但SQL Server不提供（MySQL提供）。

我知道无符号数据类型不是SQL标准（SQL-2003）的一部分，但对我来说似乎仍然很浪费。

不包括这些内容的原因是什么（在SQL Server或标准中）？

— 罗姆海因
source

11

还请问SQL Server设计团队.....：您是否真的还会最大化2十亿个INT IDENTITY值？真？！？！？！如果您要处理的行超过20亿行，我敢打赌，您可以保留一些磁盘空间，并使用BIGINT作为标识....

— marc_s 2010年

6

你是什么意思marc_s？这只是连续50年每800ms插入一次，您的表没有这种活动吗？:)

— Mike M.

21

@Mike M：并不是我们所有人都在研究米老鼠应用程序...在不到2年的时间里，我们已经使用了超过30亿个bigint。峰值大于每秒2000行。

— gbn 2010年

5

@gbn我的意思不是暗示没有人会承受如此大的负担。但是，正如已经说过的，如果您确实每秒有2000行以上的数据，那么额外的2B并不能解决您的问题。

— Mike M. 2010年

9

@Mike M和@marc_s，如果我正在使用具有20亿行表的系统，那么我可能会注意浪费的存储。我可能会注意索引页面大小和索引扫描性能。在这种情况下，我不想浪费空间。

— Romhein

64

如果我不得不猜测，我会说他们正在努力避免类型的扩散。一般来说，无符号整数不能做任何有符号整数不能做的事情。对于需要2147483648和4294967296之间的数字的情况，您可能应该使用8字节整数，因为该数字最终还会超过4294967296。

— 杰夫·霍恩比
source

3

我想这是我们最接近该问题答案的方法。谢谢。

— 罗姆海因

8

如果“类型扩散”可以节省一些空间/金钱，那么您为什么认为这可能是邪恶的。

— 塞缪尔

1

按行值获取行也将比较慢（即ORDER BY ABS(Id)），尤其是如果列是集群主键时。例如，使用32位Unix时间戳通常是一种方便的方法，可以将标准SQL日期时间减少4个字节。

— Groo 2014年

52

为此，您可以使用-2,147,483,648作为种子值。

Identity(-2147483648, 1)

— CFreitas
source

46

我在Microsoft Office Dev Center上找到了类似的问题。

Jim Hogg（程序经理）的答复包含添加未签名的int的优点和缺点。主要缺点是实现隐式类型转换的规则成为正确的噩梦。

该请求已关闭，显示为“无法解决”。

— 安东尼·K
source

该链接不再起作用，因此我无法阅读原始答案。但我相信问题不在于这是一场噩梦；而是一场噩梦。这是没有标准说明如何执行的。例如，他们可以做MySQL所做的事情（我不认为其他DBMS支持UNSIGNED），但是如果另一个DBMS添加了对标志的支持，他们可以使用不同的规则。转换设计很重要。JavaScript是一个例子，说明了当它没有被认真对待时会发生什么。

— Federico Razzoli

更新的链接-Jim Hogg在MSSN Office开发人员论坛上的评论。

— Anthony K

1

他们不支持SIGNED和UNSIGNED关键字，因为它们不是标准的。在SQL标准中，所有数字类型都是带符号的。

MySQL扩展名UNSIGNED（和SIGNED，这是默认设置），可用于在相同数量的字节中存储较高的无符号数，并禁止使用负数。

— 费德里科·拉佐利（Federico Razzoli）
source