Почему отрицательный id или ноль считается плохой практикой?

Почему отрицательный id или ноль считается плохой практикой при вставке первичного ключа в таблицу базы данных?

Я думаю, что это может быть полезно в некоторых случаях, но люди говорят, что это не рекомендуется, несмотря на то, что они никогда не говорят/не знают почему.

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

Ответ 1

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

Насколько я знаю, есть три причины считать это плохой практикой.

Он нарушает принцип наименьшего удивления.
Некоторые люди предполагают, что все идентификационные номера являются неотрицательными.
Некоторые люди используют отрицательные числа для обозначения ошибок.

Первый имеет некоторую юридическую силу. Вы никогда не видите SQL-примеры или ответы на SO, в которых используются отрицательные идентификационные номера. (Я собираюсь изменить это, начиная с сегодняшнего дня.)

Второе и третье являются следствиями первого, поскольку программисты часто принимают неожиданное поведение. (Это напоминает мне об обнаружении того, что VBA позволит мне умножить две даты, возвращая число, которое будет выражено, по-моему, в квадратных датах.)

Для номера 2 программисты приложений могут вводить тонкие ошибки, не допуская места для знака в коде пользовательского интерфейса, который может сделать -123456 похожим на 123456.

Третий относится к написанию кода, который возвращает номера идентификаторов. Код, возвращающий один номер id, может возвращать -1 в качестве кода ошибки. Но в большинстве случаев -1 является действительным идентификационным номером. (Большинство баз данных не ограничивают номера идентификаторов диапазоном неотрицательных целых чисел.)

Ответ 2

Ответ @Mike Sherrill 'Cat Recall' неверен. ИМХО.

Отрицательные. Причина отказа от использования отрицательных значений для идентификаторов заключается в том, что отрицательные числа не переносимы. Бинарное представление десятичного значения зависит от базовой численной архитектуры, и это влияет на то, как отрицательное десятичное значение будет представлено в неотрицательном потоковом формате (например, hex, base36 и т.д.). Точно так же не используются значения с плавающей запятой в качестве идентификаторов, хотя в рамках ограничений одной архитектуры это теоретически возможно.

Zero: Zero может служить идентификатором. Это не рекомендуется, потому что это часто означает пустое значение поля/NULL.

Ответ 3

Есть более 51 миллиона сайтов, обсуждающих эту проблему.

Я согласен с @Mike Sherrill, и вполне вероятно, что NULLs/Empty fields или Negative Ids создают серьезные проблемы при определении истинных значений. Он не служит никакой информационной цели и может привести только к неправильным ответам и недоверию в самой базе данных.

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