.NET: Позвольте АННУЛИРУЕТ в полях DB?

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

Пуристы попросят вас создать новую таблицу с левым соединением для записи этого значения. Реалист изменит существующую таблицу и добавит нулевое значение.

Определенно есть случаи, когда уместны нули. Универсальный тип Nullable был добавлен в платформу .net для типов значений по той же причине.

Нулевое значение иногда является допустимым значением столбца, но я бы посоветовал вместо этого добавить значения по умолчанию и сделать столбец ненулевым.

Если у вас есть существующие данные, которые нужно учитывать, вам нужно будет выполнить обновление, например:

update TableA set ColumnA = 'default value' where ColumnA is null 

... если вы хотите наложить «не нулевое значение» на существующие данные.

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

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

Из-за проблем, которые могут возникнуть с NULL, было принято решение прекратить их использование. Однако, как и большинство подобных движений, он вышел из-под контроля до такой степени, что некоторые люди фанатично настаивают на том, что значения NULL никогда не должны использоваться в базе данных. Я пробыл в этом лагере много лет, пока не обнаружил, что он немного переусердствует.

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

Часто вам нужно сохранить необязательное числовое значение, и многие люди скажут вам просто сохранить ноль, чтобы указать «нет значения», но это еще худший антипаттерн хранения магического значения, которое на самом деле означает что-то еще.Что, если тогда вы не можете использовать ноль для одного поля, потому что ноль также считается значимым значением или потому что это значение используется как кратное делителю, поэтому вам нужно использовать какое-то другое магическое значение (-1? ) для этого поля в этом случае, и теперь у вас есть более серьезная проблема, потому что все ваши необязательные числовые поля теперь ведут себя по-другому. Ой.

Даты - еще более убедительный кандидат на поля, допускающие значение NULL. Стандартное значение «без значения», которое люди используют в .NET, - это неназначенное значение DateTime по умолчанию, которым является DateTime.MinValue, или, более конкретно, 1 января 0001. Однако вы не можете записать это магическое значение в базу данных SQL, поскольку минимальное значение по умолчанию для поле SQL Server DATETIME - 1 января 1973 года. Теперь у вас должно быть что-то, что проверяет, правильно ли вы переводите эти значения, поскольку они записываются в базу данных и считываются из нее, и вы должны иметь повсюду защитное кодирование, которое проверяет чтобы узнать, меньше ли ваши поля даты, чем SqlDateTime.MinValue, нужно просто проверить, равны ли они DateTime.MinValue. Двойной Ой.

Я предпочитаю иметь дело со значениями такими, какие они есть на самом деле, а не создавать множество искусственных конструкций, чтобы скрыть истинное значение и использование поля. Если поле вполне может не иметь значения, сделайте его допускающим значение NULL, а также сделайте его допускающим значение NULL в объектах вашего приложения (если ваш язык поддерживает такую ​​вещь). Затем, каждый раз, когда вы используете это поле, вы должны учитывать, что следует делать в случае, если оно равно NULL, но на самом деле это хорошо.Обычно я против того, чтобы заставлять разработчиков тратить мозговые циклы на ненужную сложность кода, но это потому, что это отвлекает внимание от реальной решаемой бизнес-проблемы; однако в этом случае отсутствие ценности ЯВЛЯЕТСЯ частью истинной бизнес-проблемы и должно быть продумано. Если вы просто устанавливаете это значение по умолчанию, то разработчик, пишущий формулу или алгоритм, с меньшей вероятностью будет продумывать те граничные условия, в которых значения отсутствуют, и может даже не осознавать в то время, что существует вероятность того, что эти значения отсутствуют. .

NULL - это болезнь на лице человечества, которую следует искоренить. Однако, к сожалению, современные системы и языки (особенно SQL) не справляются со столь радикальной перестройкой нынешнего мышления. Фактически, SQL является главным виновником этой пародии.

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