Это - хорошая практика для установки всех столбцов базы данных как NOT NULL?

Вы не должны забывать устанавливать not null там, где это необходимо, использовать проверочные ограничения, если применимо, не забывать об уникальных ограничениях, создавать правильные индексы и чистить зубы после каждого приема пищи и перед сном :)

В большинстве случаев вы можете использовать not null и должны использовать not null. Легче изменить не null-> null, чем в противоположном направлении, но, например, в Oracle пустая строка обрабатывается как null, поэтому очевидно, что вы не можете использовать ее все время.

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

Нулевые значения могут быть очень удобными; во-первых, они прекрасно сжимаются. Однако они могут стать неприятным сюрпризом, если вы их не ожидаете, поэтому, если у вас не может быть ученика без имени, сделайте этот столбец НЕ ПУСТОЙ. (С другой стороны, отчества ... возможно, вы хотите иметь пустую строку по умолчанию, а может и нет - достойные аргументы в обоих направлениях)

Изобретатель ссылки NULL (1965) недавно назвал это своей «ошибкой на миллиард долларов»: http://qconlondon.com/london-2009/presentation/Null+References : + Ошибка + Миллиард + Доллар

Такие языки, как Scala, SML и Haskell по умолчанию не имеют значения NULL: NULL называется «Option» или «Maybe» и требует специального синтаксиса и проверок.

Со временем, когда были изобретены базы данных, разрешение NULL по умолчанию считалось все более опасным и нежелательным. Должны ли следовать базы данных? Возможно.

По возможности используйте NOT NULL.

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

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

Краткий ответ: это зависит от того, что вы храните.

Я вижу таблицу (или две), в которой все НЕ НУЛИ или все НУЛИ. Но вся база данных?

IMO, использование опции NULLable должно быть минимизировано. Приложение должно указать подходящее значение для «несуществующего» состояния. Я думаю, что в Peoplesoft приложение ставит 0 для числовых значений и пробел для столбцов Char, где значение не существует.

Можно было бы спорить, почему так называемое подходящее значение не может быть NULL.

Поскольку реализация SQL обрабатывает значения NULL совершенно по-другому.

Например, 1 = NULL и 0 = NULL оба приводят к false! NULL = NULL ложно! Значение NULL в GROUP BY и других агрегатных функциях также приводит к неожиданным результатам.

Согласно теории отношений NULL является злом.

Однако ваш вопрос относится к практике.

Итак, в той степени, в которой вы хотите, чтобы ваш чтобы соответствовать небесным идеалам теории, да, избегайте NULL , как если бы это была чума, холера и СПИД все в одном.

В той степени, в которой эти дрянные реализации называются «СУБД SQL» «не оставляйте вам другого выбора, да, (нюхайте) используйте их.

РЕДАКТИРОВАТЬ

Кто-то упомянул« бизнес-правила »в качестве руководства для« уместности »в принятом ответе, а некоторые другие поддержали это замечание. Это полная чушь. Бизнес-правила всегда могут обойтись без NULL s и единственного указания на «соответствие»

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

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

Проблема в том, что значение NULL открыто для интерпретации. Это может означать « здесь нет значения » или может означать « у нас еще нет значения, поэтому мы должны продолжать спрашивать его у пользователя». Если вы его используете, вы захотите ознакомиться с трехзначной логикой SQL и такими функциями, как COALESCE и т. Д.

Тем не менее, поскольку Клетус и другие имеют сказал, что если вы правильно используете NULL , это может быть полезно.

If your data can actually BE "unknown", and it's important to record that fact, then yes, use a NULL. Bear in mind that sometimes you need to differentiate between "unknown" and "not relevant" - for example, a DateTime field in one of my databases can either be the SQL Server minimum date (not applicable), NULL (unknown), or any other date (known value).

For fields which don't really have business rules depending on them - I'm talking about "Comments", "Description", "Notes" columns here - then I set them to default to empty strings, as (a) it saves dealing with nulls, and (b) they are never "unknown" - they just aren't filled in, which logically is a known empty value.

E.g.:

CREATE TABLE Computer (
  Id INT IDENTITY PRIMARY KEY
  , Name NVARCHAR(16) NOT NULL
  , ...[other fields]...
  , Comments NVARCHAR(255) NOT NULL
      CONSTRAINT DF_Computer_Comments DEFAULT (N'')
)

If you don't supply a value to Comments, it defaults to empty.

Если вы не можете узнать значение во время вставки, вам действительно должно быть разрешено пустое значение. Например, предположим, что у вас есть запись, которая включает два поля: дату начала и дату окончания. Вы знаете дату начала, когда вставлена ​​запись, но не дату окончания. Создание фальшивой даты для ввода в это поле просто для того, чтобы избежать нулей, по меньшей мере, глупо.

В реальной жизни принудительный ввод данных в поле причиняет не меньше вреда, чем отсутствие принудительного ввода данных. Если у вас есть поле электронной почты, и вы не знаете адрес электронной почты клиента, то пользователь должен что-то придумать, чтобы ввести в обязательное поле. Вероятно, то, что они придумывают, может быть не таким, как вы бы хотели, чтобы они придумывали что-то вроде " Предположим, у вас есть запись, которая включает два поля: дату начала и дату окончания. Вы знаете дату начала, когда вставлена ​​запись, но не дату окончания. Создание фальшивой даты для ввода в это поле просто для того, чтобы избежать нулей, по меньшей мере, глупо.

В реальной жизни принудительный ввод данных в поле причиняет не меньше вреда, чем отсутствие принудительного ввода данных. Если у вас есть поле электронной почты, и вы не знаете адрес электронной почты клиента, тогда пользователь должен что-то придумать, чтобы ввести в обязательное поле. Вероятно, то, что они придумывают, может быть не таким, как вы бы хотели, чтобы они придумывали что-то вроде " Предположим, у вас есть запись, которая включает два поля: дату начала и дату окончания. Вы знаете дату начала, когда вставлена ​​запись, но не дату окончания. Создание фальшивой даты для ввода в это поле просто для того, чтобы избежать нулей, по меньшей мере, глупо.

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

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

В реальной жизни принудительный ввод данных в поле причиняет не меньше вреда, чем отсутствие принудительного ввода данных. Если у вас есть поле электронной почты, и вы не знаете адрес электронной почты клиента, то пользователь должен что-то придумать, чтобы ввести в обязательное поле. Вероятно, то, что они придумывают, может быть не таким, как вы бы хотели, чтобы они придумывали что-то вроде "thisistupid@ass.com ". Иногда эта неверная информация возвращается клиенту или поставщику в потоке данных, и ваша компания выглядит действительно глупо. Я знаю, так как обрабатываю много этих каналов, поступающих от наших клиентов. Приятно в поле электронной почты есть такие слова: «его секретарь - толстая блондинка», «этот парень - придурок» и т. д.

В бизнес-приложениях я всегда удалял НЕ НУЛИ, потому что пользователям не нравилось, что их заставляют вводить данные, которые они не знали. Это зависит от таблицы, но я установил для большинства полей значение NULL и только минимальное количество полей установил значение NOT NULL.