TSQL - когда использовать 'not null' - PullRequest
4 голосов
/ 05 марта 2009

Какие общие рекомендации следует соблюдать при рассмотрении вопроса о том, следует ли отмечать поле «не ноль», а не просто объявлять все, кроме первичного ключа, ноль?

Должны ли поля 'not null' иметь значения DEFAULT?

Ответы [ 5 ]

8 голосов
/ 05 марта 2009

Зависит от того, как вы хотите, чтобы ваше приложение работало.

  • Во-первых, никогда не будет возможной строки, в которой это значение НЕ содержит значимых данных, затем используйте NOT NULL. То есть это значение всегда будет значимым и что-то будет представлять.
  • Хотите ли вы, чтобы значение всегда заполнялось пользователем или программистом в какой-либо форме или в каком-либо виде? Используйте NOT NULL без DEFAULT
  • Хотите, чтобы это было необязательно для пользователей и программистов? Используйте NOT NULL с DEFAULT
4 голосов
/ 05 марта 2009

Я думаю, у вас есть 2 вопроса:

Вы должны пометить поля как не нулевые?

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

Должны ли нулевые поля иметь значения по умолчанию?

Только при наличии очевидного значения по умолчанию. Например, поле «Оплачено» таблицы счетов может иметь значение по умолчанию 0 (false). В целом, все работает наоборот - если поле имеет значение по умолчанию, то оно, вероятно, также должно быть не нулевым.

Не создавайте значения по умолчанию только ради значений по умолчанию - если поле не должно быть нулевым, но универсального значения по умолчанию не существует, оставьте его таковым. Это гарантирует, что любые операторы INSERT должны предоставлять значение для этого поля.

1 голос
/ 05 марта 2009

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

0 голосов
/ 06 марта 2009

Поля, отличные от NULL, должны иметь значения по умолчанию, если они уместны, особенно если вы добавляете новое поле в таблицу (или изменяете поле с разрешения на пустые значения на недопустимые значения на пустые) и вам необходимо задать значение для всех существующих записей. Однако значение по умолчанию не подходит или не доступно для всех возможных полей. Например, у нас есть таблица персон, фамилия не может быть нулевой. Мы не можем назначить фамилию по умолчанию, но если у человека нет имени, запись не создается. С другой стороны, у вас может быть поле DateCreated со значением по умолчанию для текущей даты. Это также поле, которое вы хотели бы иметь как ненулевое, и вы хотели бы убедиться, что текущая дата была указана независимо от того, была ли запись вставлена ​​из пользовательского интерфейса, из импорта или из окна запроса.

0 голосов
/ 05 марта 2009

Делай то, что семантически правильно.

  • NULL - не всегда существует
  • NOT NULL - всегда существует

Старайтесь не определять и сохранять искусственные значения, такие как «Не выбрано значение» для раскрывающегося поля или «Нет менеджера» для менеджера сотрудника.

Использование значений по умолчанию зависит от того, как вставляются данные. Если есть пользовательский интерфейс с проверкой, вам не нужны настройки по умолчанию, ИМХО.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...