Я просто вступаю в проект и имеет довольно большой бэкэнд базы данных. Я начал копаться в этой базе данных, и 95% полей имеют значение NULL.
Это обычная практика в мире баз данных? Я просто скромный программист, а не администратор базы данных, но я бы подумал, что вы захотите свести поля с нулевым значением до минимума, только там, где они имеют смысл.
Является ли это "запахом кода", если большинство столбцов имеют значение NULL?
Значения по умолчанию, как правило, являются исключением, и NULL являются нормой, по моему опыту.
Правда, нули раздражают.
Это также чрезвычайно полезно, потому что null является лучшим индикатором "NO VALUE". Конкретное значение по умолчанию очень вводит в заблуждение, и вы можете потерять информацию или ввести путаницу по дороге.
Любой, кто разработал приложение ввода данных, знает, насколько распространено это для некоторых полей, чтобы быть неизвестным во время ввода - даже для столбцов, которые являются критичными для бизнеса, для ответа на вопрос @Chris McCall.
Однако "запах кода" является просто индикатором того, что что-то может быть закодировано небрежным способом. Вы используете запахи, чтобы идентифицировать вещи, которые требуют больше исследований, а не вещи, которые необходимо изменить.
Итак, если вы видите столбцы с нулевым значением так последовательно, вы правы, чтобы быть подозрительными. Это может означать, что кто-то ленился или боялся объявить столбцы NOT NULL однозначно. Вы можете оправдать свой собственный анализ.
Я из лагеря Extreme NO: я постоянно избегаю NULL. Отложив в сторону фундаментальные соображения относительно того, что они на самом деле имеют в виду (потому что разговаривайте с разными людьми, вы получите разные ответы, такие как "нет значения", "неизвестное значение", "отсутствует", "моя кошка-имбирь под названием" Нуль "), худшая проблема NULL - это то, что они часто разрушают ваши запросы таинственным образом.
Я потерял подсчет количества раз, когда мне приходилось отлаживать запрос (ну, может быть, 9), и проследил проблему до соединения с NULL. Если ваш код нуждается в ISNULL для восстановления соединений, то есть вероятность того, что вы также потеряли применимость индекса и производительность.
Если вы do должны хранить значение "missing/unknown/null/cat" (и это то, что я предпочитаю избегать), лучше быть явным.
Специалисты в NULL могут не согласиться. Использование NULL имеет тенденцию разбивать толпы SQL по середине.
По моему опыту, интенсивное использование NULL было положительно коррелировано с злоупотреблением базой данных, но я бы не стал вырезать это в каменные таблетки как некоторый Закон Природы. Мой опыт - это только мой опыт.
EDIT: дополнительная мысль. Вполне возможно, что те, кто являются нейтральными расистами, такими как я, более взволнованы нормализацией, чем те, кто про-NULL. Я не думаю, что бешеные нормализаторы будут слишком довольны рваными краями на своих столах, которые могут принимать NULL. Множество нулевых значений может указывать на то, что разработчики баз данных не имеют серьезной нормализации. Поэтому вместо того, чтобы NULL предлагать код "плохо", он может альтернативно предложить философскую позицию разработчиков по нормализации. Возможно, это доходит. Просто мысль.
Не знаю, считаю ли я это всегда плохим, но если столбцы добавляются, потому что одна запись (или, может быть, несколько) должна иметь значения, а большинство - нет, то это указывает на довольно плоскую таблицу состав. Если вы видите имена столбцов, такие как "addr1", "addr2", "addr3", тогда он воняет!
Готов поспорить, что большинство столбцов, которые у вас есть, могут быть удалены и представлены в других таблицах. Вы можете найти "ненулевые" с помощью отношения внешнего ключа. Это увеличит количество подключений, которые вы будете делать, но может быть больше preformant, что "где не col1 равно null".
Мне кажется, следует избегать столбцов с нулевым значением. Где семантика домена позволяет использовать значение, которое явно указывает отсутствующие данные, оно должно использоваться вместо NULL.
Например, представьте таблицу, содержащую поле Comment. Большинство разработчиков разместили здесь NULL, чтобы указать, что в столбце нет данных. (И, надеюсь, контрольное ограничение, которое запрещает строки нулевой длины, чтобы мы имели известное "значение", указывающее на отсутствие значения.) Мой подход обычно противоположный. Столбец Comment NOT NULL, а строка нулевой длины указывает на отсутствие значения. (Я использую ограничение проверки, чтобы гарантировать, что строка нулевой длины действительно является строкой нулевой длины, а не пробелом.)
Итак, зачем мне это делать? Две причины:
NULL требует специальной логики в SQL, и этот метод избегает этого.NULL. Например, если вы используете Microsoft ADO.NET, константа DBNull.Value указывает NULL, и вы должны ее проверить. Использование строки нулевой длины в столбце NOT NULL устраняет необходимость.Несмотря на все это, существует множество обстоятельств, в которых NULL являются точными. На самом деле, я не возражаю против их использования в приведенном выше сценарии, хотя это не будет моим предпочтительным способом.
Что бы вы ни делали, будьте добры к тем, кто будет использовать ваши столы. Быть последовательным. Разрешите им с уверенностью SELECT. Позвольте мне объяснить, что я имею в виду. Недавно я работал над проектом, чья база данных не была разработана мной. Почти каждый столбец был обнуляемым и не имел ограничений. Не было согласованности в отношении того, что представляет собой отсутствие ценности. Это может быть NULL, строка с нулевой длиной или даже куча пробелов и часто была. (Как этот суп ценностей попал туда, я не знаю.)
Представьте себе уродливый код, который разработчик должен написать, чтобы найти все эти записи с отсутствующим полем Comment в этом сценарии:
SELECT * FROM Foo WHERE LEN(ISNULL(Comment, '')) = 0
Удивительно, но есть разработчики, которые считают это вполне приемлемым, даже нормальным, несмотря на возможные последствия для производительности. Лучше будет:
SELECT * FROM Foo WHERE Comment IS NULL
или
SELECT * FROM Foo WHERE Comment = ''
Если ваша таблица спроектирована правильно, для получения качественных данных можно использовать два вышеуказанных оператора SQL.
Короче говоря, я бы сказал, да, это, вероятно, запах кода.
Независимо от того, является ли столбец допустимым или нет, это очень важно и должно быть тщательно определено. Вопрос должен оцениваться для каждой колонки. Я не верю в один "лучший опыт" по умолчанию для NULL. "Лучшая практика" для меня заключается в том, чтобы полностью устранить неопределенность во время проектирования и/или рефакторинга таблицы.
Для начала, ни один из ваших столбцов первичного ключа не будет иметь значение NULL. Затем я сильно склоняюсь к NOT NULL для чего-либо, что является внешним ключом.
Некоторые другие вещи, которые я считаю:
Критерии, в которых NULL следует избегать:
money - есть ли действительно вероятность того, что эта сумма будет неизвестна?
Критерии, в которых NULL могут быть оправданы наиболее часто:
datetime - нет зарезервированных дат, поэтому NULL - это ваш лучший вариант
Другие типы данных:
char/varchar столбцы - для кодов/идентификаторов - NOT NULL почти исключительно
int - в основном NOT NULL, если это не похоже на "количество детей", где вы хотите отличить неизвестный ответ.
Нет, должно ли поле быть нулевым или нет, является концепцией данных и не может быть запахом кода. Независимо от того, являются ли NULL раздражающими для кода, не имеет ничего общего с полезностью наличия полей с возможностью NULL.
Я боюсь, что это (очень распространенный) запах. Посмотрите C.J. Даты написания по этой теме.
Как наилучшая практика, если столбец не должен быть нулевым, то он должен быть отмечен как таковой. Тем не менее, я не верю в то, что схожу с ума.
Я так думаю. Если вам не нужны данные, это не важно для вашего бизнеса. Если это важно для вашей компании, это необходимо.
Все это полностью зависит от объема и требований проекта. Я бы не использовал число полей с нулевым значением в качестве показателя для плохо написанного или разработанного кода. Посмотрите на бизнес-домен, если в базе данных имеется много невообразимых полей, которые могут быть нулевыми в базе данных, тогда у вас есть некоторые проблемы.
По моему опыту, это проблема, когда Null и Not Null не соответствуют требуемому полю/не обязательному полю.
В реальности вероятность того, что это действительно все необязательные поля. Если вы обнаружите в бизнес-уровне или уровне пользовательского интерфейса, что эти поля необходимы, то я думаю, что это означает, что модель данных отклонилась от модели бизнес-объекта и является признаком чрезмерно консервативных политик изменения БД или надзора.
Если вы запустите генератор выборочных данных в своих данных, а затем попробуйте загрузить данные, которые являются действительными в соответствии с SQL, вы сразу узнаете, соответствуют ли правила.
Это похоже на много, возможно, это значит, что вы должны хотя бы расследовать. Обратите внимание: если это зрелый продукт с большим количеством данных, убедить кого-либо изменить структуру может быть сложно. Чем раньше на этапе проектирования вы поймаете что-то вроде этого, тем легче исправить все связанные коды, чтобы настроить изменения.
Плохо ли, что они использовали нули, будет зависеть от того, будут ли столбцы, допускающие нули, выглядеть так, как если бы они были связанными таблицами (домашний телефон, сотовый телефон, рабочий телефон и т.д., которые должны быть в телефонном столе со спутником) или если они выглядят подобные вещи, которые могут быть неприменимы ко всем записям (возможно, это может быть связанная таблица с отношением "один к одному" ) или могут не быть известны во время ввода данных (возможно, хорошо). Я также хотел бы проверить, действительно ли они имеют значение alwAys (тогда вы могли бы изменить значение null, если информация действительно требуется логикой busniess). Если у вас есть несколько записей с нулевым
По моему опыту, много полей с нулевым значением в большой базе данных, как и у вас, очень нормально. Учитывая это, возможно, используется множество приложений, написанных разными людьми. Создание нулевых столбцов является раздражающим, но, возможно, это лучший способ сохранить приложение надежным.
Один из многих способов сопоставить наследование (например, объекты С#) с базой данных - создать таблицу для класса в верхней части иерархии, а затем добавить столбцы для всех других классов. Столбцы должны быть нулевыми, если в базе данных хранится объект другого подкласса. Это называется Отображение наследования по одной таблице (или Иерархия карт для A Единый стол) и является стандартным шаблоном проектирования.
Побочным эффектом сопоставления наследования по одной таблице является то, что большинство столбцов имеют значение NULL.
Также в Oracle пустая строка (длина 0) считается пустой, поэтому в некоторых компаниях все столбцы строк становятся допустимыми для NULL даже на SqlServer. (только потому, что первый клиент хочет, чтобы программное обеспечение на SqlServer не означало, что у 2-го клиента нет Oracle DBA, который не позволит SqlServer подключиться к сети)
Выбросить противоположное мнение. Каждое отдельное поле в базе данных должно быть нулевым. Нет ничего более неприятного, чем работа с базой данных, которая на каждой отдельной вкладке вызывает исключение из требуемого этого или требуемого. Ничего не требуется.
Есть одно исключение из этого, ключи. Очевидно, что все первичные и внешние ключи должны быть соблюдены.
Задача приложения должна проверять данные и базу данных, чтобы просто хранить и извлекать то, что вы им даете. Если он обрабатывает логику валидации даже так же просто, как null или нет, то null делает проект более сложным, чтобы поддерживать разные правила, распространяющиеся на все.