Лучше всего знать о нормальных формах, так это то, что они являются гидами и проводниками, которых нельзя упрямо придерживаться. Когда мир академических наук сталкивается с реальным миром, вы редко находите много выживших воинов адемии.
Ответ на этот вопрос заключается в том, что его нормально использовать нули. Просто оцените вашу ситуацию и решите, хотите ли вы, чтобы они отображались в таблице или свернули данные в другую связанную таблицу, если вы считаете, что отношение нулевых значений к фактическим значениям слишком велико.
Как друг любите говорить: «Не позволяйте совершенству быть врагом добра». Подумайте, Вольтер также сказал это. 8) [/ д2]
Нулевые маркеры в порядке. Действительно, они есть.
Это огромная банка червей, потому что NULL может означать так много вещей:
Некоторые из их можно избежать путем нормализации, некоторые из них можно избежать из-за наличия значения в этом столбце («N / A»), некоторые из них могут быть смягчены за счет наличия отдельного столбца для объяснения присутствия NULL (" N / K "," N / A "и т. Д.).
Это также банда червей, потому что синтаксис SQL, необходимый для их поиска, отличается от синтаксиса ненулевых значений, к ним трудно присоединяться , и они обычно не включены в индексные записи.
Из-за прежней причины вы найдете случаи, когда нуль является неизбежным.
Из-за последней причины вы все равно должны сделать все возможное, чтобы свести к минимуму их число.
Несмотря на это, всегда используйте ограничения NOT NULL для защиты от нулей, где требуется значение.
Один аргумент против нулей состоит в том, что они не имеют четко определенной интерпретации. Если поле имеет нулевое значение, это можно интерпретировать как любое из следующего:
Некоторые дизайнеры схем требуют, чтобы все значения и типы данных имели четко определенные интерпретации, поэтому нули являются плохими .
Нули отрицательно просматриваются с точки зрения нормализации базы данных. Идея состоит в том, что если значение может быть ничем, вы действительно должны разделить это на другую разреженную таблицу, чтобы вам не требовались строки для элементов, которые не имеют значения.
Это попытка убедиться все данные действительны и оценены.
В некоторых случаях полезно иметь нулевое поле, особенно если вы хотите избежать еще одного соединения по причинам производительности (хотя это не должно быть проблемой, если база данных двигатель настроен должным образом, за исключением необычных сценариев высокой производительности.)
-Aamam
В то время как технические значения NULL в порядке, как значение поля, они довольно часто неодобрились. В зависимости от того, как данные записываются в вашу базу данных, возможно (и обычно) заканчиваться пустым строковым значением в поле, а не NULL. Таким образом, любой запрос, который имеет это поле как часть предложения WHERE, должен будет обрабатывать оба сценария, которые являются ненужными нажатиями клавиш.
Основная проблема с ошибками заключается в том, что у них есть специальная семантика, которая может давать неожиданные результаты при сравнении, агрегатах и объединениях.
Существует множество других тонкостей для нулей. В SQL для Smarties у Джо Селко есть целая глава по этому вопросу и является хорошей книгой и стоит читать в любом случае. Некоторыми примерами мест, где нули являются хорошим решением, являются:
Некоторые примеры мест, где вам может понадобиться избегать использования нулей, потому что они могут вызвать тонкие ошибки.
''
) отлично подходит для этого. Это экономит необходимость обработки нулей в качестве специального случая. Опять же, книга Целько - хорошее отношение к этой теме.
В базу данных значение null переводится как «У меня нет значения для этого». Это означает, что (интересно), логический столбец, который допускает null, является совершенно приемлемым и появляется во многих схемах базы данных. Напротив, если у вас есть логическое значение в вашем коде, которое может иметь значение «true», «false» или «undefined», вы, скорее всего, увидите, что ваш код рано или поздно завершится: d)
Итак, да, если вам нужно разрешить возможность того, что поле вообще не имеет значения, то допустимость нулей в столбце вполне приемлема. Это значительно лучше, чем потенциальные альтернативы (пустые строки, ноль и т. Д.)
В соответствии с строгой реляционной алгеброй нули не нужны. Однако для любого практического проекта они необходимы.
Во-первых, многие реальные данные неизвестны или неприменимы, а nulls хорошо реализуют это поведение. Во-вторых, они делают взгляды и внешние соединения более практичными.
Существует другая альтернатива использованию «N / A» или «N / K» или пустой строки - отдельная таблица.
Например. если мы можем или не можем знать номер телефона клиента:
CREATE TABLE Customer (ID int PRIMARY KEY, Name varchar(100) NOT NULL, Address varchar(200) NOT NULL);
CREATE TABLE CustomerPhone (ID int PRIMARY KEY, Phone varchar(20) NOT NULL, CONSTRAINT FK_CustomerPhone_Customer FOREIGN KEY (ID) REFERENCES Customer (ID));
Если мы не знаем номер телефона, мы просто не добавляем строку во вторую таблицу.
Я думаю, что вопрос сводится к тому, что вы интерпретируете значение NULL для обозначения. Да, существует много интерпретаций для значения NULL, однако некоторые из них, размещенные здесь, никогда не должны использоваться. Истинный смысл NULL определяется контекстом вашего приложения и не должен означать больше одного. Например, одно предложение заключалось в том, что NULL в поле даты рождения указывает на то, что человек все еще жив. Это опасно.
Во всей простоте определите NULL и придерживайтесь его. Я использую его для обозначения «значение в этом поле пока неизвестно». Это значит, и ТОЛЬКО это. Если вам нужно, чтобы это означало что-то еще AS WELL, вам нужно пересмотреть свою модель данных.
Вы найдете пошаговые системы сбора данных, которые не могут не иметь нулей в базе данных, потому что порядок заданий / сбор данных очень редко совпадает с логической моделью данных.
Или вы можете по умолчанию использовать значения (требуя, чтобы код обрабатывал эти значения по умолчанию). Вы можете предположить, что все строки пустые, а не нулевые, например, в вашей модели.
Или вы можете иметь промежуточную таблицу базы данных для сбора данных, которая продолжается до тех пор, пока все данные не будут получены, прежде чем вы заполняете фактические таблицы базы данных , Это большая работа.
Нули с ними сложно работать, но они имеют смысл в некоторых случаях.
Предположим, что у вас есть таблица счетов с столбцом «PaidDate», у которого есть значение даты. Что вы помещаете в эту колонку до того, как счет был оплачен (если вы не знаете заранее, когда он будет оплачен)? Это не может быть пустая строка, потому что это неверная дата. Не имеет смысла давать ему произвольную дату (например, 1/1/1900), потому что эта дата просто неверна. Кажется, единственное разумное значение - NULL, потому что оно не имеет значения.
Работа с нулями в базе данных имеет несколько проблем, но базы данных хорошо их обрабатывают. Реальные проблемы - это когда вы загружаете нули из своей базы данных в код приложения. Вот где я нашел, что все труднее. Например, в .NET дата в строго типизированном наборе данных (имитирующая структуру БД) является типом значения и не может быть нулевым. Таким образом, вы должны создавать обходные пути.
Избегайте нулевых значений, если это возможно, но не исключайте их из-за того, что они имеют действительное использование.
Нет ничего плохого в использовании NULL для полей данных. Вы должны быть осторожны при установке ключей в нуль. Первичные ключи никогда не должны быть NULL. Внешние ключи могут быть нулевыми, но вы должны быть осторожны, чтобы не создавать сиротские записи.
Если что-то «не существует», вы должны использовать NULL вместо пустой строки или другого флага.
Все сводится к нормализации в сравнении с простотой использования и проблемами производительности.
Если вы собираетесь придерживаться полных правил нормализации, вы закончите писать материал, который выглядит так:
Выберите 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 логической логики и т. д. - я предлагаю этот подробный совет:
Я думаю, что вы вводите в заблуждение концептуальное моделирование данных с помощью моделирования физических данных.
В 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, я стараюсь избегать этого, когда смогу.