Mail.ruПочтаМой МирОдноклассникиВКонтактеИгрыЗнакомстваНовостиКалендарьОблакоЗаметкиВсе проекты

Подскажите. В базе данных лучше оставлять значения NULL или заполнять ячейки значениями по умолчанию (0)?

Максим Сидоров Профи (548), закрыт 13 лет назад
Дополнен 13 лет назад
Чт оменьше съедает места на диске. Понятно, что тогда прийдется обрабатывать значение NULL (очень не люблю с этим работать) . NULL съедает место, или эт ополное отсутствие записи на диске?
Лучший ответ
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. Зная что это не перегрузит базу.
Остальные ответы
Владимир Серов Искусственный Интеллект (169326) 13 лет назад
В нормальном режиме разницы нет, место все равно резервируется под тип данных (целое, длинное целое, с плавающей т. и т. д) - 1-3 бита
Максим СидоровПрофи (548) 13 лет назад
спасибо, значит без разницы. Лучше по мне так 0 ставить (или другое по умолчанию), А то исключения NULL часто ошибки дают
Похожие вопросы