Обычно рекомендуется установить все столбцы базы данных как NOT NULL или нет? Обоснуйте свой ответ.
Является ли хорошей практикой устанавливать все столбцы базы данных как NOT NULL?
Ответ 1
Нет. Рекомендуется установить столбцы в NULL, если это необходимо.
Ответ 2
Я не согласен с правилом "где это необходимо". На самом деле достаточно безопасно, чтобы установить любой столбец NOT NULL; а затем измените столбцы, чтобы они имели значение NULL, когда они вам понадобятся. С другой стороны, если вы сначала разрешите значения NULL, а затем решите, что не хотите их разрешать, это может быть намного труднее сделать.
Это может привести к тому, что описание таблицы/столбца вашей базы данных будет довольно уродливым, если вы сделаете это чрезмерно, но если вы сомневаетесь, продолжайте и ограничивайте данные.
Ответ 3
Реляционная теория утверждает, что NULL является злом.
Однако ваш вопрос относится к практике.
Итак, если вы хотите, чтобы ваши практики соответствовали небесным идеалам теории, да, избегайте NULL, как если бы это была чума, холера и СПИД все-в-одном.
В той мере, в какой эти дрянные реализации, называемые "СУБД SQL", не оставляют вам другого выбора, да, (sniff) используют их.
ИЗМЕНИТЬ
Кто-то упомянул "бизнес-правила" в качестве ориентира для "уместности" в принятом ответе, а некоторые другие поддержали это замечание. Это полное дерьмо. Бизнес-правила всегда могут обойтись без NULL, и единственным ориентиром для "уместности" являются самые недостатки любой системы SQL, которая заставляет ее загружать нереляционную систему.
Ответ 4
Изобретатель ссылки NULL (1965) недавно назвал ее своей "ошибкой в миллиард долларов": http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake
Языки, такие как Scala, SML и Haskell по умолчанию не равны NULL: NULL называется "Option" или "Maybe" и требует специального синтаксиса и проверок.
Поскольку базы данных времени были изобретены, разрешение NULL по умолчанию считается все более опасным и нежелательным. Должны ли базы данных следовать? Возможно.
Пойдите с NOT NULL, когда сможете.
Ответ 5
Если вы не можете знать значение во время вставки, вы действительно должны иметь разрешенный null. Например, предположим, что у вас есть запись, которая включает в себя два поля, дату начала и дату окончания. Вы знаете дату начала записи, но не дату окончания. Создание фальшивой даты для ввода в это поле только для того, чтобы избежать нулей, является глупым, если не сказать больше.
В реальной жизни, по крайней мере, столько же вреда вызвано принудительным вводом данных в поле, не заставляя его. Если у вас есть поле электронной почты и вы не знаете адрес электронной почты клиента, пользователь должен сделать что-то, чтобы положить в нужное поле. Вероятно, то, что они составляют, может быть не тем, что вы хотели бы, чтобы они составляли нечто вроде "[email protected]". Иногда эта плохая информация предоставляется обратно клиенту или поставщику в фиде данных, и ваша компания выглядит действительно глупо. Я знаю, как я обрабатываю много этих каналов, поступающих от наших клиентов. Приятные вещи в поле электронной почты включали: "его секретарша - толстая блондинка", "этот парень - рывок" и т.д.
Ответ 6
С моей точки зрения, хотя это может быть лучше для базы данных, это не лучше для пользователя. После того, как вы перейдете в более интерактивные приложения, вы захотите сохранить данные во временном состоянии, поэтому большинство ваших полей, вероятно, будут пустыми в этой точке.
Ответ 7
Это зависит от того, что вы пытаетесь сделать, но для многих приложений рекомендуется избегать NULL, где это возможно, — и самый надежный способ сделать это - использовать NOT NULL.
Проблема заключается в том, что смысл NULL открыт для интерпретации. Это может означать, что "никакая ценность здесь не принадлежит", или это может означать, что "у нас пока нет ценности, поэтому мы должны просить пользователя об этом". Если вы используете его, вы захотите прочитать на SQL 3-значную логику и такие функции, как COALESCE и т.д.
Тем не менее, как сказал Клетус и другие, если вы используете NULL надлежащим образом, это может быть полезно.
Ответ 8
В бизнес-приложениях я всегда удалял свои NOT NULLS, потому что пользователям не нравилось вводить данные, которые они не знали. Это зависит от таблицы, но я устанавливаю большинство своих полей в NULL и устанавливаю минимальное количество полей в NOT NULL.
Ответ 9
Если ваши данные действительно могут быть "неизвестны", и важно записать этот факт, то да, используйте NULL. Имейте в виду, что иногда вам нужно различать "неизвестные" и "не имеющие отношения к делу" - например, поле DateTime в одной из моих баз данных может быть минимальной датой SQL Server (не применимо), NULL (неизвестно) или любым другая дата (известное значение).
Для полей, которые в действительности не имеют бизнес-правил, я говорю о столбцах "Комментарии", "Описание", "Заметки" здесь, а затем я устанавливаю их по умолчанию на пустые строки, поскольку (a) он сохраняет значение null, и (b) они никогда не "неизвестны" - они просто не заполняются, что логически является известным пустым значением.
например:.
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'')
)
Если вы не указываете значение для комментариев, по умолчанию оно пусто.
Ответ 10
Я новичок, и мой ответ может быть совершенно абстинентным, но здесь мой личный подход к этому вопросу.
По моему скромному мнению, я не вижу проблемы с разрешением NULL для всех полей, кроме первичных/внешних ключей. Я знаю, что многие из вас съежились, как только я это сказал, и я уверен, что я слышал, как кто-то крикнул: "Еретик! Сжечь его на костре!" Но вот мои рассуждения:
Действительно ли это работа базы данных для обеспечения соблюдения правил о том, какие значения должны и не должны быть разрешены, за исключением, конечно, необходимости для обеспечения таких вещей, как ссылочная целостность и для управления потреблением в хранилище (имея такие вещи, как max chars set)? Не было бы проще и лучше применять все правила "null vs. not null" на уровне кода до хранения значений в базе данных?
В конце концов, это работа кода для проверки всех значений до того, как они все равно будут сохранены в базе данных, верно? Итак, почему база данных пытается узурпировать полномочия кода, также устанавливая правила о том, какие значения действительны? (В некотором смысле использование ненулевых ограничений, за исключением случаев, когда абсолютно необходимо, почти похоже на нарушение идеи "разделения проблем".) Кроме того, в любое время, когда ограничение ограничивается уровнем базы данных, оно обязательно должно выполняться в коде уровень также для предотвращения "взрыва" кода. Итак, зачем делать в два раза больше работы?
По крайней мере, для меня кажется, что все работает лучше, когда моей базе данных разрешено просто быть "тупым контейнером для хранения данных", потому что неизбежно в прошлом, когда я пытался использовать "NOT NULL" для принудительного исполнения бизнеса которое имело смысл для меня в то время, я в конце концов желаю, чтобы я этого не делал, и в конечном итоге возвращаюсь и устраняю ограничение.
Как я уже сказал, я понимаю, что я новичок, и если есть что-то, что я упускаю из виду, дайте мне знать - и постарайтесь не слишком точить меня слишком плохо:) Спасибо.
Ответ 11
Короткий ответ: это зависит от того, что вы храните.
Я вижу таблицу (или две), имеющие все NOT NULLS или все NULLS. Но полная база данных?
Ответ 12
Только для столбцов, где значение значения не имеет никакого смысла.
Нули могут быть очень удобными; с одной стороны, они сжимаются красиво. Они могут быть неприятным сюрпризом, когда вы их не ожидаете, поэтому, если у вас нет студента без имени - сделайте этот столбец NOT NULL. (Средние имена, с другой стороны... может быть, вы хотите иметь пустую строку по умолчанию, а может и нет - достойные аргументы в обоих направлениях)
Ответ 13
Не нужно забывать устанавливать нулевое значение, если это необходимо, использовать контрольные ограничения, если это применимо, не забывать об уникальных ограничениях, создавать надлежащие индексы и чистить зубы после каждого приема пищи и перед сном:)
В большинстве случаев вы можете использовать не null, и вы должны использовать не null. Легче изменить не null- > null, чем в противоположном направлении, но, например, в пустую строку Oracle обрабатывается как null, поэтому очевидно, что вы не можете использовать его все время.
Ответ 14
Какая альтернатива?
Я нашел этот вопрос в результате обсуждения на работе. Наш вопрос:
Должен ли иметь нулевой внешний ключ или таблицу ассоциаций с уникальными ограничениями? Контекст заключался в том, что иногда существует ассоциация, а иногда нет. (EG: Незапланированные или запланированные графики)
Для меня комбинация нулевого внешнего ключа с полем "set field to null on delete" была эквивалентна таблице ассоциаций, но имела два преимущества:
- Более понятно (схема была уже сложной)
- Легче найти "незапланированные" расписания с запросом "xxx is null" (не существует запроса)
В целом, иногда "null" (отсутствие информации) фактически означает что-то. Попытайтесь иметь ненулевое значение, но есть исключения.
FWIW, мы использовали Scala/Squeryl, поэтому в коде поле было "Option" и вполне безопасным.
Ответ 15
Я считаю, что если вы хотите в какой-то степени иметь гибкие и "неоднозначные" таблицы, просто используйте NoSQL, поскольку он точно построен для этой цели. В противном случае наличие значения NULL в строке является приемлемым, так как это может быть некоторый фрагмент дополнительных данных, таких как адрес 2 или номер домашнего телефона и т.д.
По моему мнению, при изменении NULL-ключа для внешних ключей одна из основных причин, по которой мы используем реляционные базы данных. Поскольку вы хотите, чтобы ваши данные были максимально плотными и согласованными.
Ответ 16
Это зависит (от типа данных)
Подумайте об этом, если непосредственная технология, которая взаимодействует с базой данных, это Python, я сделаю все NOT NULL правильным DEFAULT.
Однако вышеизложенное имеет смысл, если столбец VARCHAR со значением по умолчанию как пустая строка.
Как насчет NUMERIC, трудно найти значения по умолчанию, где NULL может передавать более подробные сведения, кроме простого значения DEFAULT=0
Для BOOLEAN еще NULL имеет смысл и т.д.
Аналогичный аргумент может быть выполнен для различных типов данных, таких как пространственные типы данных.
Ответ 17
ИМО, используя параметр NULLable, необходимо свести к минимуму. Приложение должно указывать подходящее значение для "несуществующего" состояния. В Peoplesoft, я думаю, приложение помещает 0 для числовых чисел и пробел для столбцов Char, где значение не существует.
Можно утверждать, почему так называемое подходящее значение не может быть NULL.
Поскольку реализация SQL обрабатывает значения null полностью по-разному.
Например, 1 = NULL и 0 = NULL оба результата в false! NULL = NULL является ложным! Значение NULL в GROUP BY и других агрегатных функциях также создает неожиданные результаты.