Насколько либеральным должен быть столбец NOT NULL?

Я просто прочитал ссылку Javadoc 1.5 здесь , и только код с < и > должен быть заключен внутри {@code ...}. Вот простой пример:

 /** 
 * Bla bla bla, for example:
 *
 * 
 * void X() {
 *    List{@code } a = ...;
 *    ...
 * }
 * 
* * @param ... * @return ... */ .... your code then goes here ...

23
задан RichardTheKiwi 27 January 2011 в 20:11
поделиться

15 ответов

Честно, я всегда думал, что NOT NULL должен быть значением по умолчанию. ПУСТОЙ УКАЗАТЕЛЬ является нечетным особым случаем, и необходимо изложить доводы для него каждый раз, когда Вы используете его. Плюс он намного легче изменить столбец от NOT NULL до nullable, чем это должно пойти другим путем.

28
ответ дан kquinn 27 January 2011 в 20:11
поделиться
  • 1
    @Legend: Я добавил ссылку к статье, которая обращается к теме упорядочивания набора результатов от SQL Server. – doug_w 18 June 2011 в 05:55

Любой обнуляемый столбец является нарушением третьей нормальной формы.

Но это не ответ.

Возможно, это так: в базах данных есть два типа столбцов: те, которые содержат структуру данных, и те, которые содержат содержимое данных. Ключи - это структура, вводимые пользователем поля - данные. Другие вещи - хорошо, - это призыв к суду.

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

Если у вас есть столбец, в котором содержится один из списка вариантов выбора или ноль (выбор не сделан), обычно хорошей идеей будет иметь конкретное значение «выбор не сделан», а не обнуляемый столбец. Эти типы столбцов часто участвуют в объединениях.

-1
ответ дан paulmurray 27 January 2011 в 20:11
поделиться

Использование «Not Null» или «Null» должно в первую очередь зависеть от ваших особых требований к сопротивлению.

Наличие значения Nullable означает, что существует два или три состояния (три состояния с битовыми полями)

Например; если у меня было битовое поле, которое называлось «IsApproved», и значение устанавливается на более поздней стадии, чем вставка. Тогда есть три состояния:

  1. «IsApproved» не отвечает
  2. «IsApproved» одобрено
  3. «IsApproved» не одобрено

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

0
ответ дан Andrew Harry 27 January 2011 в 20:11
поделиться

Если вы можете думать в долгосрочной перспективе, наличие в столбце значений NULL влияет на то, как вы можете создавать свои запросы. Независимо от того, используете ли вы операторы CASE, COALESCE или должны явно проверять значения NULL, вы можете принять решение за вас.

С точки зрения производительности быстрее не беспокоиться о NULLS. С точки зрения дизайна, использование NULL - это простой способ узнать, что элемент никогда не был заполнен. Полезные примеры включают столбцы «UpdatedDateTime». NULL означает, что элемент никогда не обновлялся.

Лично я допускаю NULL в большинстве ситуаций.

1
ответ дан Some Canuck 27 January 2011 в 20:11
поделиться

Я хотел бы согласиться с Дорфиром.

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

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

2
ответ дан danieltalsky 27 January 2011 в 20:11
поделиться

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

Так что да, я думаю, что SQL довольно плох. Но вы явно спрашиваете, каковы его основные недостатки. Ну, вот несколько из них:

  • Дублирующиеся строки
  • Нули
  • Порядок столбцов слева направо
  • Безымянные столбцы и повторяющиеся имена столбцов
  • Неспособность правильно поддерживать «=»
  • Указатели
  • Высокая избыточность

По моему собственному опыту, почти все «запланированные нули» "может быть лучше представлено дочерней таблицей, имеющей внешний ключ к базовой таблице. Участие в дочерней таблице не является обязательным, и именно здесь фактически делается различие между нулем / не нулем.

Это хорошо согласуется с интерпретацией отношения как логического предложения первого порядка. Это тоже просто здравый смысл. Когда кто-то не знает адрес Боба, пишет ли он в своей Rolodex:

Bob. ____

Или он просто воздерживается от заполнения адресной карточки для Боба, пока у него не будет фактический адрес для него?

Редактировать: аргумент Даты появляется на страницах 53-55 базы данных в глубине, под заголовком раздела « Почему недопустимы пустые значения ».

7
ответ дан Steven Huwig 27 January 2011 в 20:11
поделиться

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

У меня есть 2 исключения:

  1. Даты, когда дата может быть неизвестна (например, DivorcedOn)
  2. Необязательные внешние связи ключей (MarriedToPersonId). Хотя иногда я использовал «пустые» строки в таблице внешнего ключа и делал обязательным отношение (например, JobDescriptionCode)

Я также иногда использовал явные битовые поля для «неизвестно» / «не set "(например, JobDescriptionCode и IsEmployeed).

У меня есть несколько основных причин, по которым:

  1. NULL всегда будут вызывать проблемы в числовых полях. Всегда. Всегда. Всегда. Неважно, насколько вы осторожны, выберите X + Y, так как произойдет Total, и он вернет NULL.
  2. Значения NULL могут легко вызвать проблемы в строковых полях, обычно в адресных полях (например, выберите AddrLine1 + AddrLine2 из Адреса).
  3. Защита от NULL на уровне бизнес-логики - это утомительная трата усилий ... просто не впускайте их в БД, и вы можете сохранить сотни строк кода.

Мои предпочтения по умолчанию:

  • Строки -> "", иначе пустая строка
  • Числа -> 0
  • Даты -> Сегодня или NULL (см. Исключение № 1)
  • Бит -> ложь
9
ответ дан user53794 27 January 2011 в 20:11
поделиться

Ошибка на стороне NOT NULL. В какой-то момент вам придется решить, что означает «NULL» в вашем приложении - скорее всего, для разных столбцов это будет по-разному. Некоторые из распространенных случаев: «не указано», «неизвестно», «неприменимо», «еще не произошло» и т. Д. Вы будете знать, когда вам нужно одно из этих значений, а затем вы можете соответствующим образом разрешить столбец NULLable и закодируйте логику вокруг него.

Разрешение случайным вещам быть NULL, рано или поздно, всегда кошмар IME. Используйте NULL осторожно и экономно - и знайте, что это значит в вашей логике.

Редактировать: Кажется, есть идея, что я выступаю за НЕТ нулевых столбцов, когда-либо. Это нелепо. NULL полезен , но только там, где ожидается.

Хороший пример - пример Le Dorfier DateOfDeath. NULL DateOfDeath будет означать «еще не произошло». Теперь я могу написать мнение LivingPersons WHERE DateOfDeath IS NULL.

Но что означает NULL OrderDate? Что заказ еще не сделан? Даже если есть запись в таблице заказов? Как насчет пустого адреса? Именно эти мысли должны пройти через вашу голову, прежде чем вы позволите NULL быть значением.

Возвращаясь к DateOfDeath - запрос людей WHERE DateOfDeath > '1/1/1999' не вернул бы NULL-записей - даже если мы логически знаем, что они должны умереть после 1999 . Это то, что вы хотите? Если нет, то лучше включить OR DateOfDeath IS NULL в этот запрос. Если вы разрешите всем столбцам быть NULL, вам придется думать об этом каждый раз, когда вы пишете запрос . IME, это слишком много для умственного налога для 10% или около того столбцов, которые на самом деле имеют законное значение, когда они равны NULL.

11
ответ дан Mark Brackett 27 January 2011 в 20:11
поделиться

Там нет никаких существенных последствий производительности. Даже не думайте рассматривать это как проблему. Для этого требуется огромный антипаттерн ранней оптимизации.

«Должен ли я отмечать в качестве NOT NULL только те столбцы, которые обязательно должны быть заполнены для того, чтобы строка вообще имела какое-либо значение для моего приложения?»

Да. Это так просто. Вам гораздо лучше с NULLable столбцом без каких-либо значений NULL в нем, чем с потребностью в NULL и необходимостью имитировать его. И в любом случае, любые неоднозначные случаи лучше отфильтровывать в ваших бизнес-правилах.


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

Есть еще один аргумент для пустых полей, который, на мой взгляд, является наиболее убедительным, это аргумент Use Case. Мы все были подвержены формам ввода данных, которые требуют значений для некоторых полей; и мы все отказались от форм, где у нас не было разумных значений для обязательных полей. В конечном счете, приложение, форма и дизайн базы данных могут быть защищены только в том случае, если они отражают требования пользователя; и ясно, что существует множество столбцов базы данных, для которых пользователи не могут представлять никакой ценности - иногда в определенных точках бизнес-процесса, иногда когда-либо.

14
ответ дан dkretz 27 January 2011 в 20:11
поделиться
1112 Спасибо за отличные ответы, ребята. Вы дали мне много размышлений и помогли мне сформировать мое собственное мнение / стратегию, которая сводится к следующему:

Разрешить пустые значения if-and-only-if, если нулевое значение в этом столбце будет иметь конкретное значение для вашего приложения.

Пара общих значений для нуля:

  • Все, что исходит непосредственно от пользователя
    • Здесь нуль означает «пользователь не вошел»
    • Для этих столбцов лучше разрешить нулевые значения, иначе вы просто получите ввод типа asdasd@asd.com .
  • Внешние ключи для отношений «0 или 1»
    • null означает «нет связанной строки»
    • Так что разрешите пустые значения для этих столбцов
    • Это один является спорным , но это мое мнение.

В общем, если вы не можете придумать полезного значения для нуля в столбце, это должно быть NOT NULL. Вы всегда можете изменить его на nullable позже.

Пример такого рода вещей, которыми я закончил:

create table SalesOrderLine (
    Id int identity primary key,
    -- a line must have exactly one header:
    IdHeader int not null foreign key references SalesOrderHeader, 
    LineNumber int not null, -- a line must have a line number
    IdItem int not null, -- cannot have null item
    Quantity decimal not null, -- maybe could sell 0, but not null
    UnitPrice decimal not null, -- price can be 0, but not null
    -- a null delivery address means not for delivery:
    IdDeliveryAddress int foreign key references Address, 
    Comment varchar(100), -- null means user skipped it
    Cancelled bit not null default (0) -- true boolean, not three-state!
    Delivered datetime, -- null means not yet delivered
    Logged datetime not null default (GetDate()) -- must be filled out
)
4
ответ дан Community 27 January 2011 в 20:11
поделиться

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

Один из моих любимых вариантов в отношении NULL:

SELECT F1 FROM T WHERE F2 <> 'OK'

... который (по крайней мере в DB2) не будет содержать строк, где f2 равен нулю - потому что в реляционном жаргоне, ( NULL <> 'ОК') NULL. Но ваше намерение было вернуть все не-ОК строки. Вам нужен дополнительный предикат ИЛИ, или вместо этого напишите F2 DISTINCT FROM 'OK' (что, в первую очередь, является специальным кодированием).

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

Джо Селко пишет об этом в SQL For Smarties - ловушка использования NULL в приложении заключается в том, что его значение, ну, в общем, не определено. Это может означать неизвестный, неинициализированный, неполный, неприменимый - или, как в немом примере выше, означает ли это ОК или не-ОК?

4
ответ дан twblamer 27 January 2011 в 20:11
поделиться

, Каковы последствия производительности маленьких по сравнению с большими количествами столбцов NOT NULL?

Это может указывать очевидное, но , когда столбец nullable, каждая запись потребует 1 дополнительного бита устройства хранения данных. Так столбец BIT использует на 100% больше устройства хранения данных, когда это будет nullable, в то время как UNIQUEIDENTIFIER использует устройства хранения данных только на 0,8% больше, когда это будет nullable.

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

1
ответ дан Portman 27 January 2011 в 20:11
поделиться

Лично я думаю, что необходимо отметить столбцы как Пустой указатель или не пустые на основе того, какие данные они содержат, если существует подлинное требование для данных, чтобы всегда быть там, и известны ли данные всегда во время входа. Отмечание столбца как не пустой, когда у пользователей нет данных, вызовет затем для составления данных, которые делают все данные бесполезными (это, как Вы заканчиваете с данными спама, такими как почтовое поле, содержащее "thisissilly@Ihatethisaplication.com"). При отказе потребовать чего-то, что должно быть там, чтобы процесс работал (говорят, что поле ключа для показа, что клиент сделал порядком) одинаково глупо. Пустой недостаток, не пустой, является проблемой целостности данных в основе, сделайте то, что имеет большую часть смысла к хранению Ваших применимых данных.

2
ответ дан HLGEM 27 January 2011 в 20:11
поделиться

Палка с NOT NULL на всем, пока кто-то не пищит с болью об этом. Тогда удалите его на одном столбце за один раз, максимально неохотно. Избегайте аннулирует в Вашем DB так, как Вы можете, столько, сколько Вы можете.

2
ответ дан Jonathan Leffler 27 January 2011 в 20:11
поделиться

Я нашел маркировку столбца, поскольку NOT NULL обычно является хорошей идеей, если у Вас нет полезного значения для ПУСТОГО УКАЗАТЕЛЯ в столбце. Иначе можно неожиданно найти ПУСТОЙ УКАЗАТЕЛЬ там позже, когда Вы понимаете, что не хотите его, и изменение более трудно.

10
ответ дан singpolyma 27 January 2011 в 20:11
поделиться
Другие вопросы по тегам:

Похожие вопросы: