Si vous essayez de vous donner une brève réponse à votre doute, si vous exécutez les skip(n).take(m)
méthodes sur linq (avec SQL 2005/2008 comme serveur de base de données), votre requête utilisera l' Select ROW_NUMBER() Over ...
instruction, avec en quelque sorte une pagination directe dans le moteur SQL.
En vous donnant un exemple, j'ai une table db appelée mtcity
et j'ai écrit la requête suivante (fonctionne également avec linq aux entités):
using (DataClasses1DataContext c = new DataClasses1DataContext())
{
var query = (from MtCity2 c1 in c.MtCity2s
select c1).Skip(3).Take(3);
//Doing something with the query.
}
La requête résultante sera:
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]
Ce qui est un accès aux données fenêtré (plutôt cool, btw cuz retournera des données depuis le tout début et accédera à la table tant que les conditions sont remplies). Ce sera très similaire à:
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
Sauf que, cette deuxième requête sera exécutée plus rapidement que le résultat linq car elle utilisera exclusivement l'index pour créer la fenêtre d'accès aux données; cela signifie que si vous avez besoin d'un filtrage, le filtrage doit être (ou doit être) dans la liste des entités (où la ligne est créée) et certains index doivent également être créés pour maintenir les bonnes performances.
Maintenant, quoi de mieux?
Si vous avez un flux de travail assez solide dans votre logique, la mise en œuvre de la méthode SQL appropriée sera compliquée. Dans ce cas, LINQ sera la solution.
Si vous pouvez réduire cette partie de la logique directement en SQL (dans une procédure stockée), ce sera encore mieux car vous pouvez implémenter la deuxième requête que je vous ai montrée (à l'aide d'index) et permettre à SQL de générer et de stocker le plan d'exécution du requête (amélioration des performances).