Как я могу избежать нулей в моей базе данных, а также представлять отсутствующие данные?

Итак, как вы проектируете без нулей? Это был первоначальный вопрос.

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

Итак, в случае "DateOfDeath" у нас есть таблица с двумя столбцами, а именно PersonId и DateOfDeath. Идентификатор ссылки PersonId в таблице Persons. Если есть нет DateOfDeath для хранения, мы не храним строку. Конец дискуссии.

Если вы сделаете внешнее соединение между этим и таблицей Persons, вы получите NULL для DateOfDeath везде, где не было строки. И если вы используете это в предложении where, вы получите обычное озадачивающее поведение в отношении 3-значной логики. Если вы выполните внутреннее соединение, строки, для которых нет DateOfDeath, просто исчезнут из соединения.

конструкция которая позволяет каждый столбец быть не Null принудительно называется шестой нормальной формой.

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

довольно просто, сохраняя только известную информацию - другими словами, предположение о закрытом мире. Стремитесь быть, по крайней мере, в Boyce Codd / пятой нормальной форме, и вы не ошибетесь.

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

требуются нули - нет необходимости их заменять

определение ENITRE NULL заключается в том, что его неизвестно - просто замена этого произвольным типом делает то же самое, так почему?

комментарии ниже:

просто попробовал это - ни Правда:

declare @x char
set @x = null

if @x = @x
begin
select 'true'
end

if @x <> @x
begin
select 'false'
end

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

NULL может / должен использоваться до тех пор, пока:

A) у вас есть бизнес-причины. Например, в таблице платежей,NULL значение оплаты будет означать, что он никогда не был оплачен. А 0.00 значение оплаты означало бы, что мы намеренно ничего не платили. Для медицинских карт a NULL значение для измерения кровяного давления будет означать, что вы не приняли BP, a 0 значение будет означать, что пациент мертв. Это значительное различие, и необходимые в некоторых приложениях.

B) ваши запросы на этот счет. Если вы понимаете влияние NULL on IN, EXISTS, операторы неравенства (как вы указали в OP) и т. д. тогда это не должно быть проблемой. Если у вас есть NULL теперь в ваших таблицах и не хотите значения для определенных приложений, вы можете использовать представления и либо COALESCE или ISNULL для заполнения различных значений, если исходная таблица имеет NULL.

EDIT:

для решения вопросов OP о неравенствах/равенствах" реального мира " с помощью NULL, Это отличный пример, который я иногда использую.

вы находитесь на вечеринке с 3 другими людьми. Вы знаете, что одного человека зовут Джон, но не знаете других.

логически, ответ на вопрос" сколько людей зовут Джо " неизвестен или NULL. В SQL это было бы что-то как

SELECT name FROM party where NAME = 'Joe' вы не получите строк, так как вы не знаете их имен. Может, это Джо, а может, и нет.

ваше неравенство будет:

SELECT name from party where NAME <> 'Joe' вы получите только возвращаемое значение для "John", так как имя Джона-это все, что вы знаете. Другие люди могут быть или не быть Джо, но у вас нет способа узнать.

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

для вашей конкретной проблемы, касающейся пола:

• вы уверены, что хотите гендерную таблицу и нести расходы на дополнительное соединение для каждого запроса? Для простых перечисляемых типов вполне разумно сделать поле int и определить 1=мужской, 2=женский, NULL=неизвестно.

Не разрешайте определять столбец как NULL, если это вообще возможно. Для меня это не имеет ничего общего с бизнес-правилом того, что вы хотите, чтобы NULL означало, что это связано с disk I\O.

в SQL Server столбец nullable, скажем, символ 10, будет принимать один бит в растровом изображении, когда null и 10 байт, когда не nullable. Итак, как наличие null повреждает дисковый ввод-вывод, так как это больно, когда значение вставляется в столбец, где раньше был null. Поскольку SQL не зарезервировал место в строке нет места, чтобы просто поместить значение, поэтому SQL Server должен перемещать данные, чтобы освободить место. Разбиение страницы, фрагментация, обновление МПОГ, если это куча и т. д. Все повредили дисковый ввод-вывод

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