rails nil в базе данных [дубликат]

Все сводится к нормализации в сравнении с простотой использования и проблемами производительности.

Если вы собираетесь придерживаться полных правил нормализации, вы закончите писать материал, который выглядит так:

Выберите c.id, c.lastname, ....... от клиента c левым join customerphonenumber cpn на c.id = cpn.customerid left join customeraddress ca на c.id = ca.customerid left join customerphonenumber2 cpn2 на c.id = cpn2.customerid и т. д. и т. д. и т. д.

Лично я считаю, что нули должны использоваться только тогда, когда вы используете это поле в качестве внешнего ключа для другой таблицы, чтобы символизировать, что эта запись не ссылается ни на что в другой таблице. Кроме этого, я считаю, что нулевые значения на самом деле очень сложны при программировании логики приложения. Поскольку нет прямого представления нулевой базы данных в большинстве языков программирования для многих типов данных, это приводит к созданию большого количества кода приложения, чтобы справиться со значением этих нулевых значений. Когда БД встречает нулевое целое число и пытается, например, добавить к нему значение 1 (aka null + 1), база данных вернет значение null, так как именно так определяется логика. Однако, когда язык программирования пытается добавить null и 1, он обычно генерирует исключение. Таким образом, ваш код заканчивается проверкой того, что делать, когда значение равно null, что часто просто приравнивается к преобразованию в 0 для чисел, пустой строке для текста и некоторой нулевой дате (1900/1/1?) Для полей даты .

Один раз, если вы используете базу данных Oracle. Если вы сохраните пустую строку в столбце типа CHAR, тогда Oracle будет принуждать значение NULL без запроса. Поэтому довольно сложно избежать значений NULL в строковых столбцах в Oracle.

Если вы используете значения NULL, научитесь использовать SQL-команду COALESCE, особенно со строковыми значениями. Затем вы можете запретить использование значений NULL в вашем языке программирования. Например, представьте себе человека, имеющего имя FirstName, MiddleName и FamilyName, но вы хотите вернуть одно поле;

  SELECT FullName = COALESCE(FirstName + ' ', '') + COALESCE(MiddleName+ ' ', '') + COALESCE(FamilyName, '') FROM Person

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

Вместо того, чтобы записывать все проблемы NULL и tristate vs логической логики и т. д. - я предлагаю этот подробный совет:

1. Не разрешать NULL в ваших столбцах, пока вы обнаружите, что добавляете магическое значение для представления отсутствующих или неполных данных.
2. Поскольку вы задаете этот вопрос, вы должны быть very осторожны в том, как вы приближаетесь к NULL. Там много неочевидных ловушек. Если вы сомневаетесь, не используйте NULL.

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

В CDM, если объект имеет необязательное поле, вы должны подтипировать объект и создать новый объект, если это поле не является ноль. Это теория в CDMs

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

Мое мнение спорно в течение дня - по умолчанию позволяет NULLs в столбцах базы данных, вероятно, худшее общепризнанной дизайнерское решение во всех RDBMS земли. Каждый производитель делает это, и это неправильно. NULL отлично подходят для определенных, специфичных, продуманных экземпляров, но идея о том, что вы должны явно запретить NULL для каждого столбца, делает небрежную нулеустойчивость более распространенной, чем она должна быть.

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

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

NULLS - это хорошо, и вы должны обращаться с ними должным образом при поиске. В SQL Server 2008 существует концепция разреженных столбцов, в которой вы также можете избежать пространства для NULL.

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

Спасибо Naveen

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

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

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

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

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

null означает, что нет значения, а 0 - нет, если вы видите 0, вы не знаете значения, если вы видите нуль, вы знаете, что это недостающее значение

Я думаю, что значения null clearer, 0 и '' запутывают, поскольку они явно не показывают намерение сохраненного значения

NULL пород. Если в некоторых случаях это не было необходимо, SQL не имел бы IS NULL и IS NOT NULL в качестве специальных случаев. NULL является корнем концептуального универсального, все остальное НЕ является NULL. Используйте NULL свободно, когда возможно, что значение данных будет отсутствовать, но не пропущено. Значения по умолчанию могут компенсировать только NULL, если они абсолютно правильны все время. Например, если у меня однобитовое поле «IsReady», это может иметь смысл для этого поля иметь значение по умолчанию false и NULL не допускается, но это неявно утверждает, что мы знаем , что все, что не готово, когда на самом деле у нас нет таких знаний. Скорее всего, в сценарии рабочего процесса лицо, которое решает, готовое или не просто не имело шансов вступить в свое мнение, так что дефолт ложного может быть действительно опасным, заставляя их игнорировать решение, которое, как представляется, имеет был сделан, но фактически был дефолт.

как в сторону, а в отношении среднего начального примера у моего отца не было среднего имени, поэтому его средний начальный результат был бы NULL - не пустым, или звездочкой - кроме армии, где его средний начальный был NMI = No Middle Initial. Как это глупо?

Я бы сказал, что Nulls обязательно следует использовать. Нет другого правильного способа представления недостатка данных. Например, было бы неправильно использовать пустую строку для представления отсутствующей строки адреса, иначе было бы неправильно использовать 0 для представления отсутствующего элемента данных возраста. Потому что и пустая строка, и 0 являются данными. Null - лучший способ представить такой сценарий.

Не стоит недооценивать сложность, которую вы создаете, создавая поле NULLable. Например, следующее, где предложение выглядит так, как оно будет соответствовать всем строкам (бит может быть только 1 или 0, правильно?)

where bitfield in (1,0)

Но если бит бит имеет значение NULLable, он пропустит некоторые. Или возьмите следующий запрос:

select * from mytable
where id not in (select id from excludetable)

Теперь, если excludetable содержит нуль и a 1, это означает:

select * from mytable
where id <> NULL and id <> 1

Но «id & lt;> NULL» является false для любого значения id, поэтому это никогда не вернет строки.

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