Цитата(SerGreY @ 2.8.2006, 10:07  ) |
| Читал, что при заполнении пустых строк значением NULL, ускоряется работа с базой? Что думаете по этому поводу? Есть ли смысл писать NULL вместо пустой строки? |
Думаю, да. Не просто же так его придумали.
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > СУБД, общие вопросы > Что писать в базу: NULL или пустую строку? |
| Автор: SerGreY 2.8.2006, 09:07 |
| Читал, что при заполнении пустых строк значением NULL, ускоряется работа с базой? Что думаете по этому поводу? Есть ли смысл писать NULL вместо пустой строки? |
| Автор: batigoal 2.8.2006, 09:18 | ||
Думаю, да. Не просто же так его придумали. |
| Автор: skyboy 2.8.2006, 10:00 | ||
есть смысл проектировать базу так, чтоб не было необходимости выбора. Потребность в неустановленных значениях бывает редко, может, можно обойтись без NULL? |
| Автор: SerGreY 2.8.2006, 10:27 | ||||
Например, как поступить применительно к полю "Примечания", которое в большинстве случаев остается пустым? |
| Автор: Mephisto 2.8.2006, 11:06 | ||
Конечно в таком случае лучше Null. А если Null это код, то нужно пользоваться осторожно. А именно использовать только Outer join, а не inner! И не ограничивать посредством Where поля которые содержаться в прикрепляемой таблице. Иначе будут потери при выборке! |
| Автор: Vit 2.8.2006, 15:45 |
| Null нужно не для скорости, а для правильности данных. Пустая строка - это строка длиной в ноль, а Null - это полное отсутствие какой-то строки. Например имеется примечание для какого-то товара. Пустая строка в примечании будет озночать что примечания нет, а Null то что это примечание возможно есть возможно нет оно просто не внесено пользователем... Пример может корявый, но в любом случае использование пустых строк и Null - это отражение бизнес-логики, а не вопрос скорости |
| Автор: chief39 8.8.2006, 12:15 |
| Если при создании поля таблицы указаь модификатор null - то к каждой записи будет добавлена метка размером в байт для этого поля Если заполнить её - поле налл, если нет - читается значение поля. Советуют не использовать налл в DDL на всяк случай, а только по необходимости(зачем ещё место тратить?  )Но если искать по есть/нету, налл/не налл, пустая/ не пустая - то, безусловно, быстрее будет проверка на налл. Вместо сверки длиного стринга будет проходить разовая проверка одного байта |
| Автор: chief39 8.8.2006, 12:43 | ||
ЗЫ: и конечно же
|
| Автор: Cashey 14.8.2006, 10:58 |
| Использование null может в последствие плохо сказатся при построении отчетов. |
| Автор: batigoal 14.8.2006, 11:24 | ||
Почему? |
| Автор: Cashey 14.8.2006, 12:28 | ||
А как по твоему пользователь отреагирует на слово null в таблице екселевского отчета, например? А оно именно так и выведется, если поля предварительно не обрабатывать перед выводом, но это уже отдельные операции, занимающие определенное время и ресурсы компьютера, но и главное труда программиста на написание кода обработчика |
| Автор: batigoal 14.8.2006, 14:47 |
| Ну так данные "сырьем" никто пользователю и не отдает обычно. Естественно, что им требуется обработка перед презентацией. |
| Автор: sergejzr 14.8.2006, 15:57 |
| Есть целая статья насчёт трёзначной логики в БД. Автор считает NULL - злом. Добавлено @ 15:57 Блин, статью найти не могу... Смысл там был в том, что отсутствие чего либо означает неправильное проектирование. |
| Автор: LSD 14.8.2006, 16:15 | ||
Теоретически верное проектирование не всегда хорошо согласуется с практикой. Например, пусть есть некий документ, у которого может быть срок действия, или он может быть без ограничения срока действия. С трехзначной логикой мы спокойно используем null, трактуя его как отсутсвие ограничения на срок действия. А как это реализовать без null значений? P.S. И кстати тогда получается, что и в языках программирования null не должно быть. |
| Автор: skyboy 14.8.2006, 16:28 | ||
Отдельная таблица со связью один-к-одному. Где есть записи - хорошо. Если записи нет - то получаем аналог null'a. Да и сам null можем получить при помощи LEFT JOIN... Вот только выносить ради этого поле "комментарий" в отдельную таблицу... Хм.... |
| Автор: LSD 14.8.2006, 16:59 | ||||
Как раз это я и имел в виду когда говорил, что:
Это будет плохо, с точки зрения производитльности и с точки зрения потребляемой памяти, если хотябы процентов 30 записей будут иметь дату окончания срока действия. |
| Автор: skyboy 14.8.2006, 21:09 | ||
не знаю, касательно памяти... если у нас этот комментарий выгружается раз в год по хитро....умной комбинации клавиш и надо только для того, чтоб к двум записям добавить по строке комментария? То лучше, как мне думается, коль это не нужное, но и не лишнее будет лежат в отдельной таблице. Кроме того, мне интересно, как реализован FullText index - не будет ли "мешать" null значения полнотекстовому поиску? |
| Автор: LSD 15.8.2006, 08:02 | ||||
1. в моем примере была дата окончания, а не комментарий 2. я говорил про случай когда хотя бы процентов 30 записей имеею дату окончания Конечно если у нас есть здоровое поле, например фотография, и оно присутсвует не во всех записях, вполне уместно вынести его в отдельную таблицу. Накладные расходы в этом случае будут малы, по сравнению с самими данными.
Для null значений, в индексе не создается записей. |
| Автор: Cashey 15.8.2006, 22:57 | ||
а я обычно подаю "холодным" всегда отслеживаю правильность заполнения данных или корректность выборки. А null иногда использую, когда надо получить заведомо отрицательное значение фильтра |