Пытаясь дать вам краткий ответ на ваши сомнения, если вы выполните skip(n).take(m)
методы на linq (с SQL 2005/2008 в качестве сервера базы данных), ваш запрос будет использоватьSelect ROW_NUMBER() Over ...
оператор с каким-то прямым разбиением на страницы в механизме SQL.
Приведу пример: у меня есть таблица db с именем, mtcity
и я написал следующий запрос (работает также с linq to entity):
using (DataClasses1DataContext c = new DataClasses1DataContext())
{
var query = (from MtCity2 c1 in c.MtCity2s
select c1).Skip(3).Take(3);
//Doing something with the query.
}
В результате будет получен следующий запрос:
SELECT [t1].[CodCity],
[t1].[CodCountry],
[t1].[CodRegion],
[t1].[Name],
[t1].[Code]
FROM (
SELECT ROW_NUMBER() OVER (
ORDER BY [t0].[CodCity],
[t0].[CodCountry],
[t0].[CodRegion],
[t0].[Name],
[t0].[Code]) AS [ROW_NUMBER],
[t0].[CodCity],
[t0].[CodCountry],
[t0].[CodRegion],
[t0].[Name],
[t0].[Code]
FROM [dbo].[MtCity] AS [t0]
) AS [t1]
WHERE [t1].[ROW_NUMBER] BETWEEN @p0 + 1 AND @p0 + @p1
ORDER BY [t1].[ROW_NUMBER]
Это оконный доступ к данным (довольно круто, кстати, cuz будет возвращать данные с самого начала и будет обращаться к таблице, пока выполняются условия). Это будет очень похоже на:
With CityEntities As
(
Select ROW_NUMBER() Over (Order By CodCity) As Row,
CodCity //here is only accessed by the Index as CodCity is the primary
From dbo.mtcity
)
Select [t0].[CodCity],
[t0].[CodCountry],
[t0].[CodRegion],
[t0].[Name],
[t0].[Code]
From CityEntities c
Inner Join dbo.MtCity t0 on c.CodCity = t0.CodCity
Where c.Row Between @p0 + 1 AND @p0 + @p1
Order By c.Row Asc
За исключением того, что этот второй запрос будет выполняться быстрее, чем результат linq, потому что он будет использовать исключительно индекс для создания окна доступа к данным; это означает, что если вам нужна какая-то фильтрация, фильтрация должна быть (или должна быть) в списке сущностей (где создается строка), а также должны быть созданы некоторые индексы для поддержания хорошей производительности.
Что лучше?
Если в вашей логике есть достаточно надежный рабочий процесс, реализация правильного способа SQL будет сложной. В этом случае решением будет LINQ.
Если вы можете понизить эту часть логики непосредственно до SQL (в хранимой процедуре), это будет еще лучше, потому что вы сможете реализовать второй запрос, который я вам показал (с использованием индексов), и позволить SQL генерировать и сохранять план выполнения для запрос (повышение производительности).