Linq при возврате считать что выбрать? - PullRequest
Новая
       9

Linq при возврате считать что выбрать?

2 голосов
/ 17 сентября 2011

Я получил глупую привычку делать это: 

return 
    (from c in db.tblUserAlerts 
     where c.userID == UserID && !c.hasRead  
     select new { c.ID }).Count();

Разве лучше (экономит память) возвращать c.ID, как предполагается, для всей записи c? Пример: 

return 
    (from c in db.tblUserAlerts 
     where c.userID == UserID && !c.hasRead 
     select c).Count();

Ответы [ 2 ]

5 голосов
/ 17 сентября 2011

Я думаю, проблема заключается в том, насколько сильно должны пройти данные.Для того, что вы пытаетесь сделать, я думаю, что наиболее эффективным было бы: 

return db.tblUserAlerts.Count(c=>c.userID == UserID && !c.hasRead);

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

РЕДАКТИРОВАТЬ: Я снова посмотрел на ваши теги и увидел, что у вас есть linq-to-sql.Если вы используете поставщик запросов, такой как LINQ to SQL, запрос переводится.Я полагаю, что переводчик запросов linq-to-sql переводит что-то вроде: 

SELECT count(c.ID) FROM tblUserAlerts WHERE c.userID == 'UserID' AND NOT c.hasRead

, в этом случае не должно быть никакой разницы в скорости, за исключением того, что LINQ-to-SQL может потребоватьсябольше работы по переводу вашего запроса, потому что в дереве выражений их больше.Эта разница в скорости будет в основном незначительной.Мой оригинальный ответ выше применим к LINQ-to-Objects.С LINQ-to-SQL, если вы не очень чувствительны к какому-либо снижению скорости (т.е. вы выполняете эту тысячу раз в узком цикле), они должны быть примерно эквивалентны.

1 голос
/ 19 сентября 2011

Наиболее очевидный способ написания этого запроса - как предложено. 

return db.tblUserAlerts.Count(c=>c.userID == UserID && !c.hasRead);

В этом случае SQL может выполнить COUNT (1) WHERE...

Маловероятно, что ваш выбор будет стоить или получить какую-либо выгоду - он переведен на SQL, а разница в выполнении COUNT(*) и COUNT(id) будет крошечной (если она вообще существует), как и будет разница в исполнении COUNT(id) и COUNT(1). Но зачем писать код, который ничего не делает? Нет необходимости выбирать что-нибудь .

Кажется странным, что вы спрашиваете

Разве лучше (экономит память) возвращать c.ID, как предполагается, для всей записи c?

но потом комментарий

это хорошая идея, но я предпочитаю писать их, как указано выше

Вы хотите написать эффективный, чистый код, который «экономит память», или вы хотите писать в соответствии со своими предпочтениями без видимой причины? Меньше кода - более чистый код - это не так, как если бы .Count(Exp<>) была неясной, редко используемой перегрузкой.

...