NULL vs Значение по умолчанию в базе данных SQL Server

Question

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

Answer 1

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

Однако ваш пробег может отличаться. Это зависит от вашего приложения. Если он обрабатывает неизвестные значения по-другому, то обязательно используйте это:

Answer 2

Я считаю, что дело доходит до предпочтения в сочетании с целью базы данных, в то время как я не слишком хорошо разбираюсь в том, как база данных SQL-сервера хранит его данные, я бы предположил, что это сделает минимальные практические различия, ve использовали как нулевые записи, так и строки по умолчанию как методы дифференцирования и никогда не замечали большой разницы в любом случае.

Answer 3

Основные ошибки, с которыми вы столкнетесь, я считаю, являются логическими ошибками.

Строки просты, но целые числа разные. Рассмотрим столбец зарплаты. По умолчанию 0, это может означать что-то отличное от NULL. NULL означает, что работник не получает зарплату, а 0 означает, что он по-прежнему должен обрабатываться по какой-либо причине.

NULL также можно использовать на внешних ключах, но, похоже, это плохая идея иметь значение по умолчанию для FK.

Answer 4

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

Проверка на NULL по сравнению с пустой строкой ('') отличается, так как вам нужно будет проверить COLUMN IS NULL ИЛИ COLUMN = ''. Сравнение COLUMN = NULL не будет работать, даже если COLUMN равно NULL, поскольку NULL не равно NULL, следовательно, оператор IS NULL.

Кроме того, объединение или объединение NULL с другими данными вызовут серьезные проблемы, поскольку что-либо, связанное с NULL, приведет к NULL. Агрегации будут игнорировать NULL и бросать предупреждение, но это может быть не поведение, которое вы хотите со средними значениями.

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

Answer 5

Я не согласен с использованием значения по умолчанию. Цель null - показать, что у вас нет информации. Пустая строка не означает, что это значение. Кроме того, если вы начинаете отклонять нули в строках, вам нужно рассмотреть другие типы данных. Числа и даты трудно получить значение, которое означает «у меня нет значения для этого поля». Если вы допустили ошибку при хранении чисел или дат в полях varchar, тогда пустая строка вместо нуля может привести к запросам, которые не работают, когда вам нужно преобразовать их в дату или числовой эквивалент для выполнения математических процессов на них (Не рекомендуется хранить дату и числовые данные в виде строк, просто узнав, что у вас могут быть некоторые, и эта схема может вызвать проблемы с тем, как они запрашиваются.) Если вы не разрешаете null для всех, кроме этих полей, вы будете совершать много и много ошибок при запросе этих полей, потому что вы не будете использовать для проверки нулей и, скорее всего, забудете это сделать. Вы можете вызвать и новый бренд проблем с запросами. Рассмотрите:

select count(myfield), myfield2 from mytable group by myfield2 

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

Answer 6

Это зависит от вас, и в основном это зависит от поведения приложения и потребностей бизнеса.

колонки по умолчанию, большую часть времени используется, когда

1. ваше приложение не хочет, чтобы ввести столбец на всех. Хорошим примером являются столбцы «аудита», если вы не ожидаете, что приложение/пользователь будет кормить, когда строка была вставлена ​​/ обновлена.
2. , используемый в некоторых модулях (веб-страница/ветровые формы и т. Д.). Например, быстрая форма регистрации принимает только желаемый идентификатор/имя пользователя, адрес электронной почты и пароль.
3. , если вы не хотите вводить данные теста вручную. Я нахожу, что ленивость разработчиков заключается в том, что диски, в основном, имеют столбцы DEFAULT без необходимости.