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

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

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

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

16
database database-design identifier least-astonishment primary-key

3 ответов

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

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

  1. это нарушает принцип наименьшего сюрприза.
  2. некоторые люди предполагают, что все идентификационные номера неотрицательны.
  3. некоторые люди используют отрицательные числа указывают на ошибки.

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

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

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

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

22

ответ @Mike Sherrill 'Cat Recall' является IMHO неправильным.

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

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

7

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

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

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

0