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

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

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

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

Пожалуйста, поделитесь своим мнением или опытом над подобной ситуацией.

Спасибо за ваш интерес.

источник

2012-01-10 Manish Basantani

Что вы хотите, если поле пустое? – msarchet

Является ли LINQ to SQL требованием жесткого ядра?Причина, по которой я спрашиваю, заключается в том, что есть накладные расходы и, возможно, лучше всего выполнить процедуры хранения или запросы по причинам производительности/памяти. –

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

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

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

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

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

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

источник

2012-01-10 15:59:10 msarchet

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

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

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

источник

2012-01-10 15:46:40

Согласен. Но это будет удар производительности! Рассмотрим итерацию по 1М строкам, с 20 свойствами (20 М) вызывает этот метод с нулевой проверкой !!! –

@ Единственный способ не проверять каждое значение - это не позволить SQL возвращать нуль. – msarchet

@Amby +1 Действительная точка, или еще лучше не использовать хранимые процедуры – Jonathan

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

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

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

источник

2012-01-10 16:02:14 Humberto

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

ответ

Смежные вопросы