Как работать с Nullable <T>типами, возвращаемыми из хранимых процедур?

Question

Мне нужно несколько советов по передовому опыту (с учетом памяти и процессорного времени) для обработки Nullable<T> полей, возвращаемых из хранимой процедуры при использовании Linq2Sql.

Пожалуйста, рассмотрите следующий сценарий и ограничения:

1. Я хочу не использовать проверку fieldValue.HasValue везде в коде.Таким образом, мне нужно заменить все Nullable<T> на обычные свойства (например, DateTime, Double, Int) некоторым значением по умолчанию.
2. Я ожидаю прочитать ~ 1 миллион объектов с ~ 20 полями типа Nullable.
3. Важным фактором является использование памяти и ЦП.
4. Требуется получить результат из сохраненного процесса в объекте (не в DataRow) и, таким образом, использовать Linq2Sql.

Пожалуйста, поделитесь своим мнением или опытом по поводу решения аналогичной ситуации.

Спасибо за проявленный интерес.

Answer 1

Лучшее решение:

• Не разрешать SQL возвращать значения NULL.

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

Следующее лучшее решение:

• Перезаписать объекты LINQToSQL get, чтобы проверить, есть ли у объекта HasValue, а затем, если не установлено, значение default(type) для поля.

Нет способа не проверять каждое значение.

Answer 2

Вы можете написать методы расширения, такие как:

public static string SafeGetString(this SqlDataReader _Reader, int _ColIndex)
{
    if (_Reader.IsDBNull(_ColIndex))
        return null; //Default value
    else
        return _Reader.GetString(_ColIndex);
}

Для каждого используемого типа (на самом деле их не так много), установите значение по умолчанию, отличное от null, если вы хотите вставить данные в типы, не допускающие значения NULL.

Answer 3

Хардкорный вариант - объединить значения в их источнике.Вы гарантируете, что нулевые значения будут оставаться в стороне от считывателей данных.

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

В качестве примечания, выборка миллионов строк из базы данных наверняка вызовет ощутимый эффект.Обычно вам нужно решить, где / когда будет меньше больно!