Почему отрицательный 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 в базе данных.