Каковы профи и минус использования значений NULL в SQL, а не значения по умолчанию?
PS. Многие подобные вопросы были заданы здесь, но никто не ответил на мой вопрос.
SQL: использование значений NULL и значений по умолчанию
Ответ 1
Значение NULL в базах данных - это система значение, которое занимает один байт хранения и указывает, что значение нет в отличие от пространства или ноль или любое другое значение по умолчанию. поле в базе данных, содержащей Значение NULL означает, что содержание эта ячейка неизвестна во время глядя на него. Колонка, которая позволяет Значения NULL также позволяют использовать строки вставлен без каких-либо значений в этом колонка. Существует несколько профи и минусы использования значений NULL в противоположность по умолчанию:
Pros
Значение NULL не содержит данных тип, поэтому может быть вставлен в любой структура данных и любая база данных колонка. Значения по умолчанию, с другой стороны необходимо иметь тип данных указано и значение по умолчанию в одном столбец может выглядеть одинаково в другом столбец, но он может быть другого тип.
NULL часто используется в схемах, где значение является необязательным. Это удобный метод для исключения ввода данных для неизвестные поля без необходимости применять дополнительные правила, например сохранение отрицательных значений в целых числах поле для представления пропущенных данных.
Так как значение NULL занимает только 1 бит пространства памяти, они могут быть полезно при оптимизации базы данных. Использование этих значений намного больше чем значения по умолчанию, например. символы 8 бит и целые числа 16bits.
Хотя ваши системные требования могут изменение со временем и значение по умолчанию типы с ними, значение NULL всегда NULL, поэтому нет необходимости обновлять тип данных.
Назначение не нулевых табличных схем также может помочь с проверкой таблицы, в некотором смысле, что столбец с Not Нулевые критерии потребуют быть вставлен. Значения по умолчанию не имеют эти возможности.
против
Значения NULL легко смешиваются с пустые строки символов, которые возвращаются пустое значение для пользователя, когда выбран. В этом смысле дефолт значения являются менее запутанными и являются более безопасный вариант, если значение по умолчанию устанавливается в пустую строку.
Если значения NULL разрешены в базы данных, они могут вызвать конструктор некоторое дополнительное время и работа, как они могут сделать логику базы данных более сложно, особенно когда есть много сравнений с нулевыми значениями в место.
Источник: Pro и cons
Ответ 2
Я не знаю, почему вы даже пытаетесь сравнить их с делами. null означает, что некоторый столбец пуст/не имеет значения, а значение по умолчанию дает значение столбца, когда мы не устанавливаем его непосредственно в запросе.
Может быть, какой-то пример будет лучшим объяснением. Скажем, у нас есть таблица member. Каждый член имеет идентификатор и имя пользователя. Возможно, у него может быть адрес электронной почты (но ему не обязательно). Также каждый член имеет столбец postCount (который увеличивается каждый раз, когда пользователь пишет сообщение). Таким образом, столбец электронной почты может иметь значение null (поскольку электронная почта не является обязательной), а столбец postCount - NOT NULL, но имеет значение по умолчанию 0 (потому что, когда мы создаем нового участника, у него нет сообщений).
Ответ 3
Нулевые значения не... значения!
Null означает "не имеет значения"... помимо аспекта базы данных, одно важное измерение неоцененных переменных или полей состоит в том, что невозможно использовать "=" (или " > ", "<" ) при сравнении переменных.
Написание чего-то вроде (VB):
if myFirstValue = mySecondValue
не возвращает ни True, ни False, если одна или обе переменные не являются значащими. Вам придется использовать "поворот", например:
if (isnull(myFirstValue) and isNull(mySecondValue)) or myFirstValue = mySecondValue
"Обычный" код, используемый при таких обстоятельствах,
if Nz(myFirstValue) = Nz(mySecondValue, defaultValue)
Не является строго правильным, поскольку неоцененные переменные будут считаться "равными" значению "defaultValue" (обычно это строка с нулевой длиной).
Несмотря на это неприятное поведение, никогда никогда не не включайте значения по умолчанию в строку нулевой длины (или "0" ) без веской причины, а упрощение сравнения значений в коде не является ценным причина.
Ответ 4
Значения NULL предназначены для указания того, что атрибут не применим или неизвестен. Есть религиозные войны, которые боролись за то, хороши они или плохо, но я попадаю в лагерь "хорошо".
Часто бывает необходимо различать известные значения из неизвестных значений во многих ситуациях, и они делают ненужное значение для тех атрибутов, которые не имеют подходящего значения по умолчанию.
Например, в то время как значение по умолчанию для банковского баланса может быть равно нулю, каково значение по умолчанию для номера мобильного телефона. Вам может потребоваться различать "клиент не имеет мобильного телефона", а "мобильный номер клиента пока неизвестен", и в этом случае пустой столбец не будет работать (и иметь дополнительный столбец для определения того, является ли этот столбец одним или другой - не очень хорошая идея).
Значения по умолчанию - это просто то, что СУБД будет помещать в столбец, если вы явно не укажете его.
Ответ 5
Для меня они несколько ортогональны.
Значения по умолчанию позволяют вам грациозно развить схему базы данных (подумайте о добавлении столбцов), не изменяя код клиента. Кроме того, они сохраняют некоторую типизацию, но, полагаясь на значения по умолчанию, это плохое IMO.
Нули: null s. Отсутствует ценность и огромная PITA при работе с Трехзначная логика.
Ответ 6
Как и во многих вещах, есть хорошие и плохие точки для каждого.
Хорошие точки значений по умолчанию: они дают вам возможность установить столбец в известное значение, если другое значение не задано. Например, при создании столбцов BOOLEAN я обычно присваиваю столбцу значение по умолчанию (TRUE или FALSE, независимо от того, что подходит) и сделать столбец NOT NULL. Таким образом, я могу быть уверен, что столбец будет иметь значение, и он будет установлен соответствующим образом.
Плохие значения значений по умолчанию: не все имеет значение по умолчанию.
Хорошие вещи о NULL: не все имеет известную ценность во все времена. Например, при создании новой строки, представляющей человека, у меня могут не быть значений для всех столбцов. Скажем, я знаю их имя, но не дату их рождения. Нецелесообразно ставить значение по умолчанию для даты рождения - людям не нравится получать поздравительные открытки 1 января (если это по умолчанию), если их день рождения на самом деле 22 июля.
Плохая информация о NULL: NULL требуют тщательной обработки. В большинстве баз данных, построенных на реляционной модели, как обычно реализуемые NULL - яд - наличие NULL в вычислении приводит к тому, что результат вычисления равен NULL. NULL, используемые в сравнении, также могут вызывать неожиданные результаты, потому что любое сравнение с NULL возвращает UNKNOWN (это не TRUE, а FALSE). Например, рассмотрим следующий PL/SQL script:
declare
nValue NUMBER;
begin
IF nValue > 0 THEN
dbms_output.put_line('nValue > 0');
ELSE
dbms_output.put_line('nValue <= 0');
END IF;
IF nValue <= 0 THEN
dbms_output.put_line('nValue <= 0');
ELSE
dbms_output.put_line('nValue > 0');
END IF;
end;
Вывод выше:
nValue <= 0
nValue > 0
Это может быть немного удивительно. У вас есть NUMBER (nValue), который меньше или равен нулю и больше нуля, по крайней мере в соответствии с этим кодом. Причина этого в том, что nValue на самом деле NULL, и все сравнения с NULL приводят к UNKNOWN вместо TRUE или FALSE. Это может привести к тонким ошибкам, которые трудно понять.
Поделитесь и наслаждайтесь.
Ответ 7
Это зависит от ситуации, но это действительно в конечном счете просто. Какой из них ближе к истине?
Многие люди имеют дело с данными, как будто это просто данные, а правда не имеет значения. Однако, когда вы говорите с заинтересованными сторонами в данных, вы обнаружите, что правда всегда имеет значение. иногда больше, иногда меньше, но это всегда имеет значение.
Значение по умолчанию полезно, если вы можете предположить, что если пользователь (или другой источник данных) предоставил значение, значение было бы по умолчанию. Если эта презумпция приносит больше вреда, тогда это хорошо, тогда NULL лучше, хотя обращение с NULL является болью в SQL.
Обратите внимание, что есть три способа, по которым могут быть реализованы значения по умолчанию. Во-первых, в приложении перед добавлением новых данных. База данных никогда не видит разницы между значением по умолчанию, предоставленным пользователем или предоставленным приложением!
Во-вторых, объявив значение по умолчанию для столбца и оставляя данные, отсутствующие в вставке.
В-третьих, подставляя значение по умолчанию во время поиска, всякий раз, когда обнаруживается NULL. Только несколько продуктов СУБД позволяют объявить этот третий режим в базе данных.
В идеальном мире данные никогда не пропадают. Если вы развиваетесь в реальном мире, требуемые данные в конечном итоге будут отсутствовать. Ваши приложения могут либо делать что-то, что имеет смысл, или что-то, что не имеет смысла, когда это происходит.
Ответ 8
Null, а значения по умолчанию - разные вещи, используемые для разных целей. Если вы пытаетесь избежать использования Null, указав все значение по умолчанию, это плохая практика, как я объясню.
Null означает, что мы не знаем, что это за значение или будет. Например, предположим, что у вас есть поле enddate. Вы не знаете, когда закончится процесс, поэтому Null является единственным подходящим значением; использование значения по умолчанию для какого-либо фальшивого выхода даты в будущем вызовет столько же проблем с программой, как и обработка Null, и, скорее всего, в моем опыте возникнет проблема с возвратом неверных результатов.
Теперь есть моменты, когда мы можем знать, какое значение должно быть, если человек, вставляющий запись, не делает этого. Например, если у вас есть поле date inserted, уместно иметь значение по умолчанию для текущей даты и не ожидать, что пользователь заполнит это. Вероятно, у вас есть лучшая информация для этого поля.
Иногда это суждение и зависит от бизнес-правил, которые вы должны применять. Предположим, что у вас есть поле speaker honoraria (какова сумма, которую платит спикер). Значение по умолчанию 0 может быть опасным, так как это может означать, что ораторы наняты, и мы не намерены ничего им платить. Также возможно, что иногда могут быть ораторы, которые жертвуют свое время для конкретного проекта (или являются сотрудниками компании и, следовательно, не оплачиваются дополнительно, чтобы говорить), где нуль является правильным значением, поэтому вы не можете использовать нуль как значение, чтобы определить, что вы не знаете, сколько должно оплачиваться этот оратор. В этом случае Null является единственным подходящим значением, и код должен вызывать проблему, если кто-то пытается добавить динамик на конференцию. В другой ситуации вы, возможно, уже знаете, что минимум любого оратора будет выплачен 3000, и только те, у кого были переговоры по другой ставке, будут данные, введенные в поле honoraria. В этом случае уместно поместить значение по умолчанию 3000. В других случаях разные клиенты могут иметь разные минимумы, поэтому по умолчанию следует обрабатывать по-разному (обычно через таблицу поиска, которая автоматически заполняет минимальное значение honoraria для этого клиента в форме ввода данных.
Итак, я считаю, что лучшим правилом является оставить значение как Null, если вы действительно не можете знать, когда данные будут введены, каково должно быть значение поля. Используйте значение по умолчанию, только оно имеет значение все время для этой конкретной ситуации и использует какой-либо другой метод для заполнения значения, если он может быть другим при разных обстоятельствах.
Ответ 9
В хранилище данных вы всегда хотели бы иметь значения по умолчанию, а не NULL.
Вместо этого у вас будет такое значение, как "неизвестно", "не готово", "отсутствует"
Это позволяет INNER JOINs эффективно выполняться в таблицах фактов и измерений, поскольку "все всегда имеет значение"
Ответ 10
Как уже сказал один ответчик, NULL не является значением.
Будьте очень полезными из всего, что провозглашено всеми, кто говорит о "значении NULL", как будто это значение.
NULL не равен самому себе. x = y дает false, если оба x и y равны NULL. x = y дает true, если оба значения x и y являются значениями по умолчанию.
Почти бесконечные последствия для этой, казалось бы, очень простой разницы. И большинство из этих последствий - мины-ловушки, которые сильно вас укусят.
Ответ 11
Две очень хорошие статьи, ориентированные на доступность, о Nulls от Allen Browne:
Аспекты работы с Nulls в коде VBA:
Статьи ориентированы на Access, но могут быть полезны для тех, кто использует любую базу данных, особенно относительные новички из-за диалогового стиля записи.
Ответ 12
Nulls НИКОГДА не сохраняйте место для хранения в DB2 для OS/390 и z/OS. Для каждого столбца с нулевым значением требуется один дополнительный байт хранилища для нулевого индикатора. Таким образом, столбец CHAR (10), который имеет значение NULL, потребует 11 байтов хранения в строке - 10 для данных и 1 для нулевого индикатора. Это происходит независимо от того, установлен ли столбец нулевым или нет.
DB2 для Linux, Unix и Windows имеет параметр сжатия, который позволяет столбцам устанавливать значение null для экономии места. Использование этой опции заставляет DB2 исключить неиспользуемое пространство из строки, где для столбцов установлено значение null. Однако этот параметр недоступен на мэйнфрейме.
REF: http://www.craigsmullins.com/bp7.htm
Итак, лучшей практикой моделирования для DB2 Z/OS является использование "NOT NULL WITH DEFAULT" в качестве стандарта для всех столбцов. То же самое следовало в некоторых крупных магазинах, которые я знал. Делает жизнь программистов более легким, не имея необходимости обращаться с индикатором Null и фактически сохраняет память, устраняя необходимость использования дополнительного байта для NULL INDICATOR.
Ответ 13
Я так ценю все это обсуждение. Я нахожусь в центре создания хранилища данных, и я использую модель Kimball довольно строго. Однако есть один очень вокальный пользователь, который ненавидит суррогатные ключи и хочет использовать NULL по всему месту. Я сказал ему, что в порядке есть столбцы NULLable для атрибутов измерений и для любых дат или чисел, которые используются в вычислениях, потому что значения по умолчанию там содержат неверные данные. Я согласен с тем, что в некоторых столбцах допускается NULL, но это делает кубирование намного лучше и надежнее, если есть суррогатный ключ для каждого внешнего ключа для измерения, даже если этот суррогат равен -1 или 0 для фиктивной записи, SQL любит целые числа для объединений, и если есть отсутствующее значение измерения, а манекен предоставляется в качестве суррогатного ключа, тогда вы получите такое же количество записей, используя одно измерение, как и для кубирования другого измерения. Однако расчеты должны выполняться правильно, и вы должны учитывать значения NULL в них. День рождения должен быть NULL, чтобы, например, возраст не был рассчитан. Я верю в хорошее управление данными и принятие этих решений с пользователями заставляет их думать о своих данных больше, чем когда-либо.