SQL Server Search, comment retourner le nombre total de lignes?

Question

J'ai une autre post qui a abouti à cette

SELECT DISTINCT 
     a.ArticleID, 
     COUNT(*) AS KeywordMatch, 
     a.Headline, 
     a.ShortDescription, 
     a.CategoryID, 
     a.ArticleSectionImage, 
     a.DatePublished 
    FROM 
     Article a 
    JOIN SearchWords sw ON a.ArticleID = sw.ArticleID 
    WHERE 
     EXISTS 
     (
      SELECT 
       1 
      FROM 
       iter_charlist_to_tbl(@temp, ' ') s 
      WHERE 
       s.nstr = sw.SearchWord 
     ) 
     AND 
      a.ArticleState = 3 
    GROUP BY 
     a.ArticleID, a.Headline, a.ShortDescription, a.CategoryID, a.ArticleSectionImage, a.DatePublished 
    ORDER BY (KeywordMatch) DESC, (a.DatePublished) DESC 

Je me sers de ce long avec LINQ to SQL pour créer la pagination pour les utilisateurs. Le problème est que j'ai besoin de savoir combien d'enregistrements ma recherche a renvoyé (nombre total de lignes), pour afficher les flèches correctes pour l'utilisateur.

Ceci est mon Linq-to-SQL Query:

int iPageNum = pageNumber; 
    int iPageSize = (int)pageSize; 

    results = data.SearchArticles(searchString).Skip((iPageNum - 1) * iPageSize).Take(iPageSize).ToList(); 

Toutes les idées?

Mon Linq-to-SQL extrait-t-il tous les enregistrements de la base de données? ou crée-t-il une requête qui ne sélectionne que les enregistrements dont j'ai besoin? Comment puis-je pointer à la requête?

Answer 1

Une approche consiste à avoir deux requêtes: une qui renvoie un nombre, et une autre qui renvoie les données.

Vous pouvez les mettre tous les deux dans un SP avec plusieurs jeux de résultats pour éviter un aller-retour DB supplémentaire. J'explique un exemple de pagination de données (y compris en fournissant un compte) en détail dans mon livre: Ultra-Fast ASP.NET. Mon approche n'utilise pas LINQ (car elle ne supporte pas plusieurs ensembles de résultats), mais c'est aussi plus rapide.

Voici une requête qui devrait compter le nombre de lignes dans le résultat (non testé, mais il devrait être proche):

;WITH SearchArticles (aid, cnt, headline, descr, cid, img, datepub) as ( 
SELECT DISTINCT 
      a.ArticleID, 
      COUNT(*) AS KeywordMatch, 
      a.Headline, 
      a.ShortDescription, 
      a.CategoryID, 
      a.ArticleSectionImage, 
      a.DatePublished 
     FROM 
      Article a 
     JOIN SearchWords sw ON a.ArticleID = sw.ArticleID 
     WHERE 
      EXISTS 
      (
        SELECT 
         1 
        FROM 
         iter_charlist_to_tbl(@temp, ' ') s 
        WHERE 
         s.nstr = sw.SearchWord 
      ) 
      AND 
        a.ArticleState = 3  
     GROUP BY 
      a.ArticleID, a.Headline, a.ShortDescription, a.CategoryID, 
      a.ArticleSectionImage, a.DatePublished 
) SELECT COUNT(*) FROM SearchArticles 

Answer 2

puisque vous récupérez l'ensemble de toute façon avec la partie de data.SearchArticles pourquoi ne pas le faire:

var results = data.SearchArticles(searchString); 
var count = results.Count(); 

results = results.Skip((iPageNum - 1) * iPageSize).Take(iPageSize).ToList(); 

dépend beaucoup de la taille des résultats de retour à si cela est OK.

Answer 3

Après avoir lu vos commentaires sur les autres réponses:

SQL Server n'a pas construit dans la pagination. Ainsi, par défaut, une requête va chercher toutes les lignes. Si une requête ne récupère pas toutes les lignes, votre objet ResultSet effectue la recherche pour vous. Si le jeu de résultats n'est pas paginé, il n'est pas nécessaire de parcourir tous les résultats pour vérifier sa propriété Count(), il doit simplement être défini correctement car SQL Server renvoie le nombre de lignes avec les données. Si vous craignez d'aller chercher trop de données en une fois et que votre resultset ne pagaie pas, vous devez d'abord sélectionner le compte, puis créer une requête capable de renvoyer la page de données souhaitée.

À côté: Vous pouvez laisser le distinct de votre choix. Puisque vous regroupez et regroupez, vous avez déjà des résultats distincts.