Для чего используются отрицательные ключи?

Несколько нововведенный в использовании стандартных баз данных SQL (в настоящее время в основном работающих с MySQL), я еще не сталкивался с этим во многих случаях.

Когда и почему полезно иметь отрицательные (или скорее подписанные) ключи, индексирующие таблицу?

Все первичные ключи - это значение, которое мы определили, это значение, которое имеет первостепенное значение в записи. Является ли этот ключ подписанным int, неподписанным int, строкой, большим двоичным объектом (на самом деле, существуют ограничения) или UUID (или каким-либо другим именем, которое он принимает сегодня), факт остается фактом, что это ключ и что он является вещь первостепенной важности.

Поскольку мы не ограничены использованием только положительно ориентированных чисел для наших ключей, имеет смысл учитывать, что число со знаком int будет доходить до ~ 2 миллиардов, а число без знака - до ~ 4 миллиардов. Но нет ничего плохого в использовании int со знаком, установке начального значения в ~ -2 миллиарда и установке шага в единицу. После ~ 2 миллиардов записей вы достигнете нуля, а затем продолжите ~ 2 миллиарда.

Что касается того, почему было бы полезно иметь «отрицательные ключи» в таблице, это тот же вопрос, что и «почему полезно иметь ключи в таблице». «Значение» ключа не влияет на его статус в качестве ключа. Ключ это ключ это ключ.

Что важно, так это если ключ действителен.

Что касается того, почему было бы полезно разрешить ключи, которые были отрицательными, я могу предложить несколько причин:

Что если вы хотите указать возврат в системе продаж в виде отрицательных номеров заказа на продажу, которые соответствуют положительному номеру заказа на продажу, что облегчает корреляцию (это наивно и плохо спроектировано, но будет работать в смысле «электронных таблиц»).

Что делать, если вы хотите иметь таблицу пользователей и указать, что те, у кого отрицательные числа, контролируются системой (именно так и поступают с пользователями в чате).

Я мог бы продолжить, но на самом деле единственная причина, по которой значение отрицательного числа имеет значение, заключается в том, если вы или я придаем ему значение. Кроме того, нет особой причины, по которой значение ключа может иметь какое-либо отношение к самому ключу.

Если мы говорим о столбцах идентификаторов или автономных номеров, само значение не должно иметь никакого значения. (иногда так и происходит, согласно сообщениям пользователей чата SO, представленных drachenstern, что я и сделал раньше)

Однако, как правило, вы потеряете половину своего диапазона, если используете целые числа со знаком.
См .: Что делать, когда поле в таблице приближается к максимальному 32-разрядному целому числу со знаком или без знака?

Другой пример: в небольших сценариях репликации использование отрицательных значений для одного сайта и положительных для другого дает некоторые неявные знания об источнике любой данной строки.

Не все системы баз данных даже поддерживают целочисленные типы без знака, MSSQL - один из тех, которые этого не делают. В этих случаях отрицательные значения возможны в полях целочисленных ключей просто потому, что они возможны в типе (вы можете использовать правила или триггеры, чтобы заблокировать их, как показано в этом примере , но, вероятно, нет необходимости добавлять накладные расходы на применение таких правил к каждые inters / update).

Что касается базы данных, то фактическое значение первичного ключа не имеет значения, если оно уникально в таблице. Для него -42 и 42 - это просто два разных числа таким же образом, как и 42 и 69 - значение будет придано только отрицательности или не значению вашего кода.

Отказ от поддержки целочисленных типов без знака, вероятно, является конструктивным решением, основанным на уменьшении сложности, т. Е. Нежелании двух разных 32-разрядных целочисленных типов беспокоиться о проверке диапазонов при назначении значений между ними. Он ограничивает число возможных индексов в поле автоматического приращения, начиная с 0 или 1 до половины, что было бы возможно для беззнакового типа (~ 2e9, а не ~ 4e9), но это редко является серьезной проблемой (если вам, вероятно, понадобится количество значений ключа той величины, которые вы, вероятно, в любом случае использовали для 64-битного типа, особенно если вы используете 64-битную архитектуру, где такие значения обрабатываются не менее эффективно, чем 32-битные), хотя, если вы хотите получить полный диапазон и чтобы придерживаться 32-битного из-за нехватки места, вы можете начать приращение с -2 147 483 647.