Является злоупотребление nullable столбцов в базе данных “запахом кода”?

Значения по умолчанию, как правило, являются исключением, а значения NULL являются нормой, по моему опыту.

Правда, значения NULL раздражают.

Это также чрезвычайно полезно, потому что NULL является лучшим индикатором " НЕВАЖНО". Конкретное значение по умолчанию вводит в заблуждение, и вы можете потерять информацию или внести путаницу в будущем.

Один из многих способов сопоставить наследование (например, объекты C #) с базой данных - это создать таблицу для класса наверху иерархии, а затем добавить столбцы для всех других классов . Столбцы должны допускать значение NULL, если в базе данных хранится объект другого подкласса. Это называется Отображение наследования одной таблицы (или Отображение иерархии в одну таблицу ) и является стандартным шаблоном проектирования.

Побочным эффектом сопоставления наследования одной таблицы является то, что большинство столбцов допускают значение NULL.

---

Также в Oracle пустая строка (длина 0) считается нулевой, поэтому в некоторых компаниях все столбцы строк допускают значение NULL даже на SqlServer.

Рекомендуется, чтобы столбец не допускал значения NULL, тогда он должен быть отмечен как таковой. Однако я не верю в полное безумие с такими вещами.

Боюсь, это (очень распространенный) запах. Посмотрите записи CJ Date по этой теме.

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

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

Думаю, да. Если вам не нужны данные, то для вашего бизнеса это не важно.

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

Не знаю, считаю ли я это всегда плохим, но если столбцы добавляются из-за того, что одна запись (или, может быть, несколько) должна иметь значения, а большинство - нет, тогда это указывает на довольно плоскую структуру таблицы. Если вы видите имена столбцов, такие как «addr1», «addr2», «addr3», то это воняет!

Я готов поспорить, что большинство имеющихся столбцов можно удалить и представить в других таблицах. Вы можете найти "ненулевые" через отношения внешнего ключа. Это увеличит количество соединений, которые вы будете выполнять, но это может быть более преформантным, чем выполнение «where not col1 is null».

Короче говоря, я бы сказал, да, вероятно, это запах кода.

Является ли столбец допускающим значение NULL или нет, очень важно и должно быть определено тщательно. Вопрос должен быть оценен по каждой колонке. Я не верю в единую "передовую практику" по умолчанию для NULL . «Лучшая практика» для меня - это тщательно решить проблему допустимости значений NULL во время проектирования и / или рефакторинга таблицы.

Для начала, ни один из ваших столбцов первичного ключа не будет иметь значение NULL. Затем я решительно склоняюсь к NOT NULL для всего, что является внешним ключом.

Некоторые другие вещи, которые я рассматриваю:

Критерии, при которых NULL следует строго избегать: деньги столбцы - существует ли действительно вероятность того, что эта сумма будет неизвестна?

Критерии, по которым NULL могут быть оправданы наиболее часто: datetime столбцы - нет зарезервированных дат, поэтому NULL - лучший вариант.

Другие типы данных: char / varchar столбцы - для кодов / идентификаторов - NOT NULL почти всегда int столбцы - в основном NOT NULL , если только это не что-то вроде «количество дочерних элементов», где вы хотите различить неизвестный ответ.

Я считаю, что столбцов, допускающих значение NULL, следует избегать. Везде, где семантика домена позволяет использовать значение, явно указывающее на отсутствующие данные, его следует использовать вместо NULL.

Например, представим себе таблицу, содержащую комментарий поле. Большинство разработчиков поместили бы здесь NULL, чтобы указать, что в столбце нет данных. (И, надеюсь, проверочное ограничение, которое запрещает строки нулевой длины, чтобы у нас было хорошо известное «значение», указывающее на отсутствие значения.) Мой подход обычно противоположный. Столбец Комментарий имеет значение NOT NULL , а строка нулевой длины указывает на отсутствие значения. (Я использую проверочное ограничение, чтобы убедиться, что строка нулевой длины действительно является строкой нулевой длины, а не пробелом.)

Итак, зачем мне это делать? Две причины:

1. NULL требуют специальной логики в SQL, и этот метод позволяет избежать этого.
2. Многие клиентские библиотеки имеют специальные значения, указывающие NULL . Например, если вы используете Microsoft ADO.NET, константа DBNull.Value указывает NULL, и вы должны проверить это. Использование строки нулевой длины в столбце NOT NULL устраняет необходимость.

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

Что бы вы ни делали, будьте добры к тем, кто будет использовать ваши таблицы. Будьте последовательны . Позвольте им уверенно ВЫБРАТЬ . Позвольте мне объяснить, что я имею в виду под этим. Недавно я работал над проектом, база данных которого была разработана не мной. Почти каждый столбец допускал значение NULL и не имел ограничений. Не было единообразия в том, что представляет собой отсутствие ценности. Это может быть NULL , строка нулевой длины или даже набор пробелов, что часто бывает. (Как этот набор ценностей попал туда, я не знаю.)

Представьте себе уродливый код, который разработчик должен написать, чтобы найти все эти записи с отсутствующим полем Комментарий в этом сценарии:

SELECT * FROM Foo WHERE LEN(ISNULL(Comment, '')) = 0

Поразительно, но есть разработчики, которые считают это вполне приемлемым, даже нормальным, несмотря на возможные последствия для производительности. Лучше было бы:

SELECT * FROM Foo WHERE Comment IS NULL

Или

SELECT * FROM Foo WHERE Comment = ''

Если ваша таблица правильно спроектирована, то два вышеупомянутых оператора SQL могут быть использованы для получения качественных данных.

Почти каждый столбец допускал значение NULL и не имел ограничений. Не было единообразия в том, что представляет собой отсутствие ценности. Это может быть NULL , строка нулевой длины или даже набор пробелов, что часто бывает. (Как этот набор ценностей попал туда, я не знаю.)

Представьте себе уродливый код, который разработчик должен написать, чтобы найти все эти записи с отсутствующим полем Комментарий в этом сценарии:

SELECT * FROM Foo WHERE LEN(ISNULL(Comment, '')) = 0

Поразительно, но есть разработчики, которые считают это вполне приемлемым, даже нормальным, несмотря на возможные последствия для производительности. Лучше было бы:

SELECT * FROM Foo WHERE Comment IS NULL

Или

SELECT * FROM Foo WHERE Comment = ''

Если ваша таблица правильно спроектирована, то два вышеупомянутых оператора SQL могут быть использованы для получения качественных данных.

Почти каждый столбец допускал значение NULL и не имел ограничений. Не было единообразия в том, что представляет собой отсутствие ценности. Это может быть NULL , строка нулевой длины или даже набор пробелов, что часто бывает. (Как этот набор ценностей попал туда, я не знаю.)

Представьте себе уродливый код, который разработчик должен написать, чтобы найти все эти записи с отсутствующим полем Комментарий в этом сценарии:

SELECT * FROM Foo WHERE LEN(ISNULL(Comment, '')) = 0

Поразительно, но есть разработчики, которые считают это вполне приемлемым, даже нормальным, несмотря на возможные последствия для производительности. Лучше было бы:

SELECT * FROM Foo WHERE Comment IS NULL

Или

SELECT * FROM Foo WHERE Comment = ''

Если ваша таблица правильно спроектирована, то два вышеупомянутых оператора SQL могут быть использованы для получения качественных данных.

или даже куча пробелов, а часто и было. (Как этот набор ценностей попал туда, я не знаю.)

Представьте себе уродливый код, который разработчик должен написать, чтобы найти все эти записи с отсутствующим полем Комментарий в этом сценарии:

SELECT * FROM Foo WHERE LEN(ISNULL(Comment, '')) = 0

Поразительно, но есть разработчики, которые считают это вполне приемлемым, даже нормальным, несмотря на возможные последствия для производительности. Лучше было бы:

SELECT * FROM Foo WHERE Comment IS NULL

Или

SELECT * FROM Foo WHERE Comment = ''

Если ваша таблица правильно спроектирована, то два вышеупомянутых оператора SQL могут быть использованы для получения качественных данных.

или даже куча пробелов, а часто и было. (Как этот набор ценностей попал туда, я не знаю.)

Представьте себе уродливый код, который разработчик должен написать, чтобы найти все эти записи с отсутствующим полем Комментарий в этом сценарии:

SELECT * FROM Foo WHERE LEN(ISNULL(Comment, '')) = 0

Поразительно, но есть разработчики, которые считают это вполне приемлемым, даже нормальным, несмотря на возможные последствия для производительности. Лучше было бы:

SELECT * FROM Foo WHERE Comment IS NULL

Или

SELECT * FROM Foo WHERE Comment = ''

Если ваша таблица правильно спроектирована, то два вышеупомянутых оператора SQL могут быть использованы для получения качественных данных.

несмотря на возможные последствия для производительности. Лучше было бы:

SELECT * FROM Foo WHERE Comment IS NULL

Или

SELECT * FROM Foo WHERE Comment = ''

Если ваша таблица правильно спроектирована, то два вышеупомянутых оператора SQL могут быть использованы для получения качественных данных.

несмотря на возможные последствия для производительности. Лучше было бы:

SELECT * FROM Foo WHERE Comment IS NULL

Или

SELECT * FROM Foo WHERE Comment = ''

Если ваша таблица правильно спроектирована, то два вышеупомянутых оператора SQL могут быть использованы для получения качественных данных.

Я из лагеря Extreme NO: я все время избегаю NULL. Отложив в сторону фундаментальные соображения о том, что они на самом деле означают (поскольку разговаривая с разными людьми, вы получите разные ответы, такие как «нет значения», «неизвестное значение», «отсутствует», «мой рыжий кот по кличке Null»), худшая проблема Причина значений NULL в том, что они часто загадочным образом портят ваши запросы.

Я сбился со счета, сколько раз мне приходилось отлаживать чей-то запрос (хорошо, может быть, 9), и отследил проблему до соединения с NULL . Если вашему коду требуется ISNULL для восстановления объединений, то, скорее всего, вы также потеряли применимость индекса и производительность с ним.

Если вы действительно должны сохранить значение «missing / unknown / null / cat» (и этого я предпочитаю избегать), лучше сказать об этом прямо.

Специалисты в области NULL могут не согласиться. Использование NULL имеет тенденцию разделять массу SQL пополам.

По моему опыту, интенсивное использование NULL положительно коррелирует со злоупотреблением базой данных, но я бы не стал вырезать это на каменных скрижалях как некий Закон природы. Мой опыт - это просто мой опыт.

РЕДАКТИРОВАТЬ: Дополнительная мысль. Возможно, что те, кто настроены против нулевых расистов, вроде меня, больше взволнованы нормализацией, чем те, кто выступает за NULL. Я не думаю, что бешеные нормализаторы были бы слишком довольны рваными краями на своих таблицах, которые могут принимать NULL. Большое количество нулей может указывать на то, что разработчики базы данных не занимаются тяжелой нормализацией. Таким образом, вместо NULL, предполагающего, что код «плохой», это может также указывать на философскую позицию разработчиков по нормализации. Может, до этого дойдет. Просто мысль.

Любой, кто разработал приложение для ввода данных, знает, насколько часто некоторые поля остаются неизвестными на момент ввода, даже для критически важных для бизнеса столбцов, для адресации @ Ответ Криса МакКолла.

Однако «запах кода» - это просто индикатор того, что что-то могло быть закодировано небрежно. Вы используете запахи, чтобы идентифицировать вещи, которые нуждаются в дополнительном исследовании, не обязательно то, что нужно изменить.

Так что да, если вы видите столбцы, допускающие значение NULL, так постоянно, вы правы в подозрении. Это может указывать на то, что кто-то ленился или боялся однозначно объявить столбцы NOT NULL . Вы можете оправдать проведение собственного анализа.

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

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

По моему опыту, это проблема, когда Null и Not Null не соответствуют обязательному / необязательному полю.

Возможно, это все необязательные поля. Если вы обнаружите на бизнес-уровне или уровне пользовательского интерфейса, что эти поля являются обязательными, то я думаю, что это означает, что модель данных отошла от модели бизнес-объектов и является признаком чрезмерно консервативной политики изменения БД или надзора.

Если вы запустите генератор образцов данных для своих данных, а затем попытаетесь загрузить данные, действительные в соответствии с SQL, вы сразу узнаете, совпадают ли правила.

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

Есть одно исключение, ключи. Очевидно, что все первичные и внешние ключи должны существовать.

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