blocks|key|1062790|text|如果要我猜的话，我会说他们是在努力避免类型的激增。一般来说，无符号整数可以做的任何事情都是有符号整数做不到的。至于当你需要一个介于2147483648和4294967296之间的数字时，你可能应该使用一个8字节的整数，因为这个数字最终也会超过4294967296。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1062791|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If I had to guess, I would say that they are trying to avoid a proliferation of types. Generally speaking there isn't anything that an unsigned integer can do that a signed integer can't do. As for the case when you need a number between 2147483648 and 4294967296 you probably should go to an 8 byte integer since the number will also eventually exceed 4294967296.

blocks|key|848524|text|为此，您可以使用-2,147,483,648作为种子值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|848525|Identity(-2147483648,+1)|code-block|syntax|javascript|848526|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

For that purpose you could use -2,147,483,648 as the seed value.

<pre><code>Identity(-2147483648, 1)
</code></pre>

blocks|key|1062924|text|我发现了一个类似的问题on+Microsoft+Office+Dev+Center.|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1062925|Jim+Hogg+(程序经理)的回复对于添加无符号整数有一些优点和缺点，主要缺点是实现隐式类型转换的规则成为正确的噩梦。|1062926|该请求被关闭为"Won't+Fix“。|1062927|entityMap|0|LINK|mutability|MUTABLE|url|https://social.msdn.microsoft.com/Forums/exchange/en-US/b91f934a-01a1-4146-9501-0dc228156e04/data-type-for-unsigned-integer?forum=transactsql^0|B|V|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

I found a similar question <a href="https://social.msdn.microsoft.com/Forums/exchange/en-US/b91f934a-01a1-4146-9501-0dc228156e04/data-type-for-unsigned-integer?forum=transactsql" rel="noreferrer">on Microsoft Office Dev Center.</a> 

The reply from Jim Hogg (Program Manager) has some pro's and con's for adding unsigned int's. The major con is the rules to implement implicit type conversions become a nightmare to get right.

The request was closed as "Won't Fix".

blocks|key|848612|text|它们不支持已签名和未签名关键字，因为它们不是标准关键字。在SQL标准中，所有数值类型都是有符号的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|848613|UNSIGNED+(和SIGNED，这是默认值)是MySQL扩展，可用于以相同的字节数存储更高的无符号数字，并且不允许使用负数。|848614|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

They don't support the SIGNED and UNSIGNED keyword because they're not standard. In SQL standard, all numeric types are signed.

UNSIGNED (and SIGNED, which is the default) are MySQL extensions that can be useful to store higher unsigned numbers in the same amount of bytes, and disallow negative numbers.

blocks|key|848664|text|以32位(8字节)整数为例。32位整数的范围是从-2%5E31到2%5E31-1。记录赋值需要31位，记录值的符号只需要1位。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|848665|所以你的问题的答案是“不必要的”。即使您分配的每个值都是正数，每个值也只会浪费1位。创建一个新的数据类型，每个值只节省1位，这不是优化存储空间的好方法。|848666|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Take 32 bit(8 byte) int for example.
The range of 32 bit int is from -2^31 to 2^31-1.
It takes 31 bit to record the value you assigned and only 1 bit to record the sign of value.
So the answer to your question is &quot;Unnecessary&quot;. Even though every value you assigned is positive, it waste only 1 bit per value. Creating a new datatype for saving only 1 bit per value is not a good way to optimize storage space.

blocks|key|848694|text|在某些情况下，SQL+server中需要无符号数字。例如，可能需要将二进制值的等价物存储为整数。在这种情况下，对于32位二进制值，必须使用64位bigint而不是32位int数据类型。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|848695|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

There are some cases where unsigned numbers are required in SQL server. For example, it may be necessary to store the equivalent of a binary value as an integer. In this case, for the 32-bit binary value, it is necessary to use 64-bit bigint instead of the 32-bit int data type.

I am specifically thinking about unsigned <code>int</code>. 

Here is a practical example: what do you do when your identity column maxes out? It's possible to either go <code>BigInt</code> (8 bytes storage instead of 4) or to refactor the application to support negative integers, and even to create your own rules as indicated in <a href="https://stackoverflow.com/questions/306291/4-byte-unsigned-int-in-sql-server/306300#306300">this answer</a>; neither of those options are optimal. 

<code>UInt</code> would be an ideal solution, but SQL Server does not offer it (where MySQL does).

I understand that unsigned datatypes are not part of the SQL standard (SQL-2003) but still seems like a waste to me. 

What is the reason of not including these (in SQL Server or in the standard)?

Why doesn't SQL Server support unsigned datatype?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋 

腾讯云代码助手

CODING DevOps

Cloud Studio

SDK中心

API中心

命令行工具

我特别考虑的是未签名的int。这里有一个实际的例子:当你的身份列达到最大值时，你该怎么做？可以使用BigInt (8字节存储而不是4字节)，也可以重构应用程序以支持负整数，甚至可以按照中的说明创建自己的规则；这两种选择都不是最优的。UInt将是一个理想的解决方案，但是SQL Server不提供它(而MySQL提供)。我知道无符号数据类型不是SQL标准(SQL-2003)的一部分，但在我看来仍然是一

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

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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