Почему SQL Server не поддерживает беззнаковый тип данных?


84

Я специально думаю о неподписанных int.

Вот практический пример: что вы делаете, когда ваш столбец идентичности достигает максимума? Можно либо пойти BigInt(хранилище 8 байтов вместо 4), либо провести рефакторинг приложения для поддержки отрицательных целых чисел и даже создать свои собственные правила, как указано в этом ответе ; ни один из этих вариантов не является оптимальным.

UInt было бы идеальным решением, но SQL Server не предлагает его (в отличие от MySQL).

Я понимаю, что беззнаковые типы данных не являются частью стандарта SQL (SQL-2003), но все же мне кажутся пустой тратой.

По какой причине они не включены (в SQL Server или в стандарт)?


11
Спросите команду разработчиков SQL Server ... также: вы действительно собираетесь максимально увеличить даже 2 МИЛЛИАРДА значений INT IDENTITY ?? ДЕЙСТВИТЕЛЬНО?!?!?! Если у вас более 2 миллиардов строк того, с чем вы имеете дело, держу пари, вы можете сэкономить немного места на диске и использовать BIGINT как IDENTITY ....
marc_s

6
Что вы имеете в виду marc_s? Это только вставка каждые 800 мс в течение 50 лет подряд, у ваших таблиц нет такой активности? :)
Майк М.

22
@Mike M: Не все из нас работают над приложениями с Микки Маусом ... мы использовали более 3 миллиардов bigint менее чем за 2 года. Пик> 2000 строк в секунду.
gbn

5
@gbn Я не имел в виду, что ни у кого не было этой нагрузки. Однако, как уже было сказано, если у вас ДЕЙСТВИТЕЛЬНО> 2000 строк в секунду, дополнительные 2Б не помогут вашему делу.
Майк М.

11
@Mike M и @marc_s, если бы я работал в системе с таблицей с 2 ​​миллиардами строк, я мог бы обратить внимание на потраченное впустую хранилище. Я могу обратить внимание на размер страницы индекса и скорость сканирования индекса. В таких условиях хотелось бы не тратить зря место.
Romhein

Ответы:


65

Если бы мне пришлось угадывать, я бы сказал, что они пытаются избежать увеличения количества типов. Вообще говоря, нет ничего, что могло бы сделать целое число без знака, чего не могло бы сделать целое число со знаком. Что касается случая, когда вам нужно число от 2147483648 до 4294967296, вам, вероятно, следует перейти к 8-байтовому целому числу, поскольку это число также в конечном итоге превысит 4294967296.


3
Думаю, это наиболее близкий ответ на этот вопрос. Благодарю.
Romhein

8
Если «распространение типов» могло сэкономить место / деньги, почему вы думаете, что это могло быть злом.
Samuel

1
Получение строк по их значению также будет медленнее (т.е. ORDER BY ABS(Id)), особенно если столбец является кластеризованным первичным ключом. Например, использование 32-битной временной метки unix часто является удобным способом сократить 4 байта стандартной даты и времени SQL.
Groo

56

Для этой цели вы можете использовать -2 147 483 648 в качестве начального значения.

Identity(-2147483648, 1)

Ха, мне очень нравится этот ответ. Я не уверен, что когда-нибудь реализовал бы его, но он определенно решил проблему неиспользования половины ваших идентификаторов.
Кевин

46

Я нашел аналогичный вопрос в Центре разработки Microsoft Office.

В ответе Джима Хогга (менеджера программ) есть несколько плюсов и минусов за добавление неподписанных int. Главный минус заключается в том, что правила реализации неявного преобразования типов становятся кошмаром.

Запрос был закрыт как «Не исправить».


Ссылка больше не работает, поэтому я не могу прочитать исходный ответ. Но я считаю, что проблема не в том, что это кошмар; дело в том, что нет стандарта, который говорит, как это делать. Например, они могут делать то, что делает MySQL (я не думаю, что другие СУБД поддерживают UNSIGNED), но если другая СУБД добавляет поддержку знаков, они могут использовать другие правила. Дизайн конверсии - важный вопрос. JavaScript - это пример того, что происходит, когда к нему не относятся всерьез.
Федерико Разцоли

Обновленная ссылка - комментарий Джима Хогга на форуме разработчиков MSSN Office.
Энтони К.

1

Они не поддерживают ключевые слова SIGNED и UNSIGNED, потому что они нестандартны. В стандарте SQL все числовые типы подписаны.

UNSIGNED (и SIGNED, что по умолчанию) - это расширения MySQL, которые могут быть полезны для хранения более высоких беззнаковых чисел в том же количестве байтов и запрета отрицательных чисел.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.