matod
Искусственный Интеллект
(188784)
13 лет назад
Если бы на ваш вопрос был бы однозначный ответ, никто бы не парился с созданием специального значения NULL и возможностью ее включения и отключения по желанию разработчика БД :)
Съедает или нет место на диске это значение - зависит от реализации конкретного формата хранения БД. В dbf - одно, в ms sql - другое.. . Но в любом случае, особой экономии вы не получите, да и не очень это нынче актуально, особенно для числовых типов. Ну, сэкономите на миллион записей 4 МБ - современные системы этого и не заметят.
Другое дело, что значение NULL принципиально отличается по смыслу от 0. Оно придумано не для экономии места, а для возможности хранения информации о том, что значение ячейки не определено. что-то вроде признака "нет данных".
К примеру, вы проектируете БД, в которой хранится кроме прочего некий числовой показатель, например показания температуры воздуха.
Оператор заносит данные в первую запись 20 градусов. Во второй день он это поле не заполняет, т. к. термометр разбился. На третий день купили новый и третья запись содержит в поле значение 22.
Потом мы хотим узнать среднюю температуру. Если мы при проектировании "для удобства" программиста сделаем поле без NULL, то результат получим не правильный (20+21+0)/3=14
В то время, как правильным ответом по известным данным будет 21 (при учете в алгоритме возможности нулов) . При этом, мы не можем исключать из рассмотрения нулевые значения, т. к. зимой температура может опускаться до 0 градусов и это значение должно влиять на среднюю температуру. На практике подобные ситуации возникают довольно часто.
Аналогично, в случае использования полей ссылок, NULL указывает на то, что ссылка не инициализирована. Для строковых полей, позволяет различать отстутсвие значения и пустую строку. Конечно, для всех этих целей можно использовать доп. поля, например битовые флаги и пр. Однако, NULL-значение в этом отношении безопаснее, т. к. при попытке выполнить операции с этим значением мы сразу заметим, что что=то пошло не так и мы пытаемся использовать неопределенные данные. А замена на 0 может приводить к скрытым ошибкам, которые не ловятся на тестировании и возникают только на определенных наборах данных.
При работе со ссылками работа запросов с join зависит от того, указан в поле нулл или 0.
Так что ответ зависит от того, что именно вы хотите хранить в поле (семантика поля) , как будете это использовать и пр. А гадание "люблю-не люблю" лучше оставить для других случаев, инструмент используется по назначению, а не по степени личной приязни. ))
Максим СидоровПрофи (548)
13 лет назад
Исчерпавающий ответ. С 0 всё понятно ,конечно по умолчанию это не всегда годиться. Но я использую данные из таблицы в алгоритмах. И если я попытаюсь сравнить два значения - один из которых будет NULL а другой 1, т омне даст ошибку, что это сравнивать нельзя. Т.е. мне перед сравнением нужно выяснять является ли значение NULL и у жпотом сравнивать. И это очень загромждает агоритм. Но всё равно спасибо за ответ!!! В моем случае буду легко пользоваться 0. Зная что это не перегрузит базу.