В чем смысл DBNull?

Дело в том, что в определенных ситуациях существует разница между значением базы данных, равным нулю, и значением .NET Null.

Например. Если вы используете ExecuteScalar (который возвращает первый столбец первой строки в результирующем наборе) и получаете нулевое значение, это означает, что выполненный SQL не вернул никаких значений. Если вы получите обратно DBNull, это означает, что значение было возвращено SQL, и оно было NULL. Вы должны быть в состоянии сказать разницу.

Я собираюсь не согласиться с тенденцией здесь. Я сделаю запись:

Я не согласен с тем, что DBNull служит какой-либо полезной цели; это вносит ненужную путаницу, но практически не приносит пользы.

Часто выдвигается аргумент, что null — недопустимая ссылка, а DBNull — шаблон нулевого объекта; ни одно из них не верно. Например:

int? x = null;

это не "неверная ссылка"; это значение null. Действительно, null означает все, что вы хотите, и, честно говоря, у меня нет абсолютно никаких проблем с работой со значениями, которые могут быть null (действительно, даже в SQL нам нужно правильно работать с null - здесь ничего не меняется). Точно так же «шаблон нулевого объекта» имеет смысл только в том случае, если вы на самом деле рассматриваете его как объект в терминах ООП, но если у нас есть значение, которое может быть «нашим значением или DBNull», тогда оно должно быть object, поэтому мы можем не делайте с ним ничего полезного.

С DBNull так много плохого:

• это заставляет вас работать с object, так как только object может содержать DBNull или другое значение
• нет реальной разницы между "может быть значением или DBNull" и "может быть значением или null"
• аргумент, что это происходит из 1.1 (pre-nullable-types), бессмысленен; мы могли бы прекрасно использовать null в 1.1
• у большинства API есть «это нуль?» методы, например DBDataReader.IsDBNull или DataRow.IsNull - ни один из них на самом деле не требует существования DBNull с точки зрения API
• DBNull терпит неудачу с точки зрения объединения с нулевым значением; value ?? defaultValue не работает, если значение равно DBNull
• DBNull.Value нельзя использовать в необязательных параметрах, так как это не константа
• семантика времени выполнения DBNull идентична семантике null; в частности, DBNull на самом деле равно DBNull, поэтому оно не выполняет работу по представлению семантики SQL
• он часто принудительно упаковывает значения типа значения, поскольку он чрезмерно использует object
• если вам нужно проверить на DBNull, вы могли бы также протестировать только на null
• это вызывает огромные проблемы для таких вещей, как параметры команды, с очень глупым поведением, что если параметр имеет значение null, он не отправляется... ну, вот идея: если вы не хотите, чтобы параметр был отправлен - не добавлять его в коллекцию параметров
• каждая ORM, о которой я могу думать, отлично работает без какой-либо потребности или использования DBNull, за исключением дополнительной неприятности при общении с кодом ADO.NET.

Единственный даже отдаленно убедительный аргумент, который я когда-либо видел для оправдания существования такого значения, находится в DataTable, при передаче значений для создания новый ряд; null означает "использовать значение по умолчанию", DBNull явно является нулем - честно говоря, этот API мог бы иметь особую обработку для этого случая - например, воображаемый DataRow.DefaultValue был бы намного лучше, чем ввод DBNull.Value, который заражает обширные участки кода бесплатно. причина.

Точно так же сценарий ExecuteScalar... в лучшем случае незначителен; если вы выполняете скалярный метод, вы ожидаете результата. В сценарии, где строк нет, возврат null не кажется таким уж ужасным. Если вам абсолютно необходимо устранить неоднозначность между «нет строк» ​​и «возвращается один единственный нуль», есть API-интерфейс для чтения.

Этот корабль уже давно уплыл, и слишком поздно его чинить. Но! Пожалуйста, не думайте, что все согласны с тем, что это "очевидно". Многие разработчики не видят ценность в этой странной морщинке в BCL.

Мне на самом деле интересно, связано ли все это с двумя вещами:

• необходимость использовать слово Nothing вместо чего-то, включающего "null" в VB
• имея возможность использовать синтаксис if(value is DBNull), который «выглядит точно так же, как SQL», а не такой хитрый if(value==null)

Резюме:

Наличие 3 вариантов (null, DBNull или фактическое значение) полезно только в том случае, если есть подлинный пример, в котором вам нужно устранить неоднозначность между 3 разными случаями. Мне еще предстоит увидеть случай, когда мне нужно представить два разных «нулевых» состояния, поэтому DBNull совершенно избыточен, учитывая, что null уже существует и имеет гораздо лучшую поддержку языка и среды выполнения.

DbNull представляет собой коробку без содержимого; null указывает на отсутствие поля.

Вы используете DBNull для отсутствующих данных. Null в языке .NET означает отсутствие указателя на объект/переменную.

Отсутствующие данные DBNull: http://msdn.microsoft.com/en-us/library/system.dbnull.value.aspx

Влияние отсутствия данных на статистику:

http://en.wikipedia.org/wiki/Missing_values

Между CLR null и DBNull есть некоторые различия. Во-первых, null в реляционных базах данных имеет другую семантику «равно»: null не равно null. CLR null равен нулю.

Но я подозреваю, что основная причина связана с тем, как значения параметров по умолчанию работают на сервере SQL и с реализацией поставщика.

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

CREATE PROC [Echo] @s varchar(MAX) = 'hello'
AS
    SELECT @s [Echo]

Хорошо структурированный код DAL должен отделять создание команд от их использования (чтобы можно было многократно использовать одну и ту же команду, например, многократно эффективно вызывать хранимую процедуру). Напишите метод, который возвращает SqlCommand, представляющий описанную выше процедуру:

SqlCommand GetEchoProc()
{
    var cmd = new SqlCommand("Echo");
    cmd.Parameters.Add("@s", SqlDbType.VarChar);
    return cmd;
}

Если теперь вы вызовете команду, не задав параметр @s, или установите для него значение (CLR) null, будет использоваться значение по умолчанию «hello». Если, с другой стороны, вы установите значение параметра в DBNull.Value, оно будет использовать его и выводить DbNull.Value.

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

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

Чтобы ответить на ваш вопрос, вы должны подумать, почему DBNull вообще существует?

DBNull необходим в узком случае использования. В противном случае это не так. Большинству людей никогда не понадобится DBNull. Я никогда не позволяю их вводить в хранилища данных, которые я разрабатываю. У меня ВСЕГДА есть значение, поэтому мои данные никогда не бывают ‹null›, я всегда выбираю тип, осмысленный как «значение по умолчанию», и мне никогда не приходится делать эту абсурдную двойную проверку всего дважды в коде, один раз для объекта null и снова ибо это DBNull, прежде чем я приведу свой объект к моему фактическому типу данных (например, Int и т. д.).

DBNull необходим в одном случае, который вам может понадобиться... если вы используете некоторые функции статистики SQL (например, медиана, среднее)... они специально обрабатывают DBNull... посмотрите эти документы... некоторые функции не включают DBNull в общем подсчете статистики... например: (сумма 87/всего 127) против (сумма 87/всего 117)... разница в том, что 10 из этих значений столбца были DBNull... вы можете видеть, что это изменится результат статистики.

Мне не нужно проектировать свои базы данных с помощью DBNull. Если бы мне когда-нибудь понадобились статистические результаты, я бы явно изобрел или добавил столбец, такой как «UserDidProvideValue», для этого одного элемента, который требует какой-то специальной обработки, потому что он не существует (например, мое общее количество 117 будет суммой полей, отмеченных UserDidProvideValue=true) ... ха-ха, лол - в моей следующей жизни как правителя Вселенной, лол - DBNull никогда бы не позволили покинуть царство SQL... весь мир программирования теперь обязан проверять все дважды... когда у вас когда-нибудь было мобильное приложение, настольное приложение или веб-сайт, которым нужно было иметь нулевое целое число? - Никогда...