какой способ лучше использовать для извлечения данных с помощью Linq? - PullRequest
1 голос
/ 21 января 2011

Я использую классы LinqToSql и хранимые процедуры для извлечения данных.

Я хотел бы знать - слишком ли плохо для производительности использовать такую ​​структуру, например

datacontext.SelectUsers().Where(s=>s.userName = varUserName && s.pass = varUserPass);

OR

лучше создать новую процедуру, например

select *
from Users 
where name = @name and pass = @pass

Ответы [ 4 ]

1 голос
/ 21 января 2011

Хранимая процедура обычно дает лучшую производительность, поскольку она будет предварительно скомпилирована.

Но использование современного SQL-сервера и Linq в большинстве случаев очень близко подходит, поскольку библиотека linq создает операторы sql, которые могут быть скомпилированы и повторно использованы adhoc..

И для более сложных операторов linq может многократно создать более эффективный запрос, который вы могли бы сделать вручную, поэтому, если производительность имеет первостепенное значение, протестируйте оба и посмотрите, какой из них лучше всего подходит для вашего решения, возможно, используйте ссылку в linqpad длясоздать SQL, затем взять этот SQL и построить хранимую процедуру:)

0 голосов
/ 21 января 2011

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

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

0 голосов
/ 21 января 2011

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

Наличие всей логики в хранимых процедурах также позволяет выполнять запросы по определенному содержимому, чтобы вы могли легконайти все процедуры с именем столбца или с определенным комментарием, это очень удобно и лучше, чем поиск во всех файлах в Visual Studio ... например, в последнее время я очень часто использую такой запрос:

SELECT ROUTINE_NAME, ROUTINE_DEFINITION 
FROM INFORMATION_SCHEMA.ROUTINES 
WHERE ROUTINE_DEFINITION LIKE '%ROLLBACK TRANSACTION%'
AND ROUTINE_TYPE='PROCEDURE'

или аналогичный:)

0 голосов
/ 21 января 2011

Очевидно, что sprocs будет стоить меньше производительности тем или иным образом, поскольку linq в конечном итоге преобразуется в запрос sql, а также потому, что с sproc вы можете формировать результаты и разрабатывать свой запрос, чтобы он весил меньше .

Но Я не уверен, что вы всегда захотите использовать sprocs, если для вас важна читабельность.

Также linq возвращает объекты, не всегда sprocs. В linq вам не нужно включать жестко запрограммированные части sproc и его параметры, тогда как в sprocs вам может понадобиться.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...