Обнуляемые типы .NET 2.0 и нулевые значения базы данных

Question

Если в версии 1 присутствовали обнуляемые типы .NET 2.0, будет ли DBNull.Value вообще не нужен?

Или нуль СУБД не имеет отношения к нолю .NET? То есть DBNull.Value все равно понадобится, независимо от того, что в .NET версии 1 уже есть типы, допускающие обнуление.

Answer 1

Обнуляемые типы в .NET позволяют рассматриваемой переменной фактически быть нулем. DBNull - это способ сказать «в другой среде это значение считалось нулевым». Так как нам нужен способ сделать различие между на самом деле null - или "нативно" null, как в нативном для нашей текущей среды выполнения - и null в другой системе, с которой мы взаимодействуем, обнуляемые типы и DBNull служат совершенно другим целям.

Answer 2

null и DBNull.Value - это две разные вещи в любой версии .NET.

Например:

public string CustomerName(int Id)
{
   SqlCommand cmd = 
         new SqlCommand("SELECT Name FROM Customer WHERE id = " + custId, conn);

   object result = cmd.ExecuteScalar();

   if (result == null)
      return "Customer not found";

   if (result == System.DBNull.Value)
      return "Customer found but name is null";

   return (string) result;
}

Ref .

Answer 3

Если System.Data.DataSetExtensions.dll что-нибудь пройти, я предполагаю, что DBNull.Value, вероятно, не существовало бы, если бы в то время были доступны типы значений, допускающие значение null.

Используя методы расширения этой библиотеки в DataRow, для столбца "foo" которого установлено значение DBNull.Value, вы получаете ...

row.Field<int?>("foo");  // returns a nullable int set to null
row.Field<int>("foo");   // throws an InvalidCastException

Это, конечно, невероятно удобно в сочетании с C # ?? оператор, когда вы хотите предоставить значение по умолчанию вместо нулевой базы данных. Лично я не терял времени на реализацию подобных методов расширения в IDataReader / IDataRecord.

Answer 4

Я не совсем согласен с этим.

Обнуляемые типы в .NET позволяют рассматриваемая переменная на самом деле ноль. DBNull это способ сказать "в другая среда, это значение было считается нулевым ". Так как нам нужно способ сделать различие между фактически нуль - или "нативно" ноль, как в родной для нашего текущего времени выполнения - и ноль в другой системе мы общаемся с обнуляемыми типами и DBNull служат совершенно разные цели.

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

Но разница в том, что null в языках программирования сигнализирует об отсутствии значения, а null == null - это истина. В базах данных ноль указывает на нечто большее, чем неизвестное значение. Поэтому null == null является ложным в базах данных; null вообще ничего не значит, потому что вы не можете определить неизвестное значение, если оно равно другому неизвестному значению. Я не уверен, что DBNull реализован таким образом, а DBNull.Value == DBNull.Value оценивается как ложное.

EDIT

Я только что проверил это, и DBNull не ведет себя должным образом. DBNull.Value == DBNull.Value оценивается как true, но должно давать false с семантикой базы данных null.