Доступ к базе данных C #: DBNull против нуля

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

При настройке этого класса для работы с Oracle мы столкнулись с интересным вопросом. Лучше использовать DBNull.Value или ноль? Есть ли какие-либо преимущества использования DBNull.Value? Кажется более «правильным» использовать нуль, так как мы отделили себя от мира БД, но есть некоторые последствия (вы не можете просто слепо, например, ToString()когда значение равно нулю), так что это определенно то, что нам нужно сделать сознательным решение о.

15.08.2008 22:23:21
4 ОТВЕТА
РЕШЕНИЕ

Я считаю, что лучше использовать ноль, а не БД нуль.

Причина в том, что, как вы сказали, вы отделяете себя от мира БД.

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

В конце концов, архитектурно я считаю, что это лучшее решение.

15
11.08.2012 16:08:41

Исходя из моего опыта, .NET DataTables и TableAdapters лучше работают с DBNull. Он также открывает несколько специальных методов при строгой типизации, таких как DataRow.IsFirstNameNull, когда он находится на месте.

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

3
11.08.2012 16:08:55

Использование DBNull.
Мы допустили какие-то проблемы при использовании null.
Если я правильно помню, вы не можете вставить пустое значение в поле, только DBNull.
Может быть связано только с Oracle, извините, я больше не знаю деталей.

1
11.08.2012 16:08:50

Если вы написали свой собственный ORM, то я бы сказал, просто используйте нуль, так как вы можете использовать его как хотите. Я полагаю, что DBNull изначально использовался только для того, чтобы обойти тот факт, что типы значений (int, DateTime и т. Д.) Не могут иметь значение null, а не возвращать какое-либо значение, например ноль или DateTime.Min, что означало бы нулевое значение (плохое, плохое). ), они создали DBNull, чтобы указать это. Может быть, было что-то еще, но я всегда предполагал, что это было причиной. Однако теперь, когда у нас есть обнуляемые типы в C # 3.0, DBNull больше не нужен. Фактически, LINQ to SQL просто использует null повсеместно. Совершенно никаких проблем. Прими будущее ... используй ноль. ;-)

7
16.08.2008 04:34:46
Я думаю, что есть еще некоторые варианты использования DBNull. По крайней мере, с помощью sqlite я могу проверить, сохранено ли в базе данных значение, возвращаемое ExecuteScalar (), или нет. Рассмотрим таблицу foo (a int, b int); с одной строкой (1, ноль). Если бы нам нужно было выполнить ExecuteScalar по команде «SELECT b FROM foo WHERE A = 1», он бы возвратил DBNull.Value (строка существует, и ноль сохраняется). Если бы я вызвал ExecuteScalar в «SELECT b FROO FER WHERE A = 2», он бы возвратил ноль (такой строки не существует). Предположительно, вы могли бы достичь того же результата с DataReader, но я ценю удобство.
fostandy 29.11.2009 14:27:36
Интересно. Используя ORM для доступа к БД, я не часто явно использую ExecuteScalar в своем коде. Я обычно заканчиваю тем, что получаю полные объекты сущностей и смотрю на их значения таким образом. Так что, если сама сущность равна нулю, это одно, а если значение равно нулю, это нечто другое. Просто разные способы сделать это. Я признаю, что ExecuteScalar более эффективен, если вам нужно только одно значение.
jeremcc 4.12.2009 17:25:24