2010-07-02 5 views
0

Salut tout le monde, j'ai une question intéressante je pense. J'ai une application Silverlight3 qui interroge une base de données SQL Server 2005 de manière asynchrone. Cependant, certains des ensembles de données que les requêtes renvoient sont énormes et je suis donc en train d'examiner la pagination des données.Pagination de données: SQL Server 2005 + SL3

Objectifs:

1) Juste dans les appels de données en temps - Je veux seulement interroger pour les données de la page 3 lorsque l'utilisateur clique pour accéder à la page 3.

2) Je veux un curseur pour contrôler les page sur laquelle je suis - SliderControl est SL3 avec son mouvement lié à un appel de procédure stockée (c'est ma supposition initiale quant à une approche).

3) Lire les données en avant comme étiquette pour le curseur. Ainsi, le curseur dira "Page 1 of 50" ou peut-être "Gant-Hart". Une sorte d'indication de l'endroit où vous êtes dans les données sans réellement interroger toutes les données jusqu'à ce que l'utilisateur laisse tomber le curseur dans la position.

Je suis presque certain que j'ai besoin de faire une sorte de requête pour obtenir le nombre total de lignes et un certain type de données de signets que la requête finira par retourner. Sinon, je ne sais pas comment scinder le curseur et je ne serais pas capable de faire des étiquettes de page (le gant pour hart stuff).

Quelqu'un a-t-il de l'expérience avec ce genre de chose? Merci.

Répondre

0

Il y a généralement au moins 2 recherches distinctes impliquées ici, la première pour obtenir les informations du pager et une seconde pour récupérer les données appropriées à la page en cours. Le pager (curseur) doit connaître le nombre total de résultats qui seraient renvoyés si vous n'utilisiez pas la pagination.

Ceci est nécessaire pour afficher le joli indicateur "Nombre total de résultats" pour votre utilisation et pour calculer le nombre total de pages que vous avez. Dans votre cas, vous allez vouloir mettre en forme un joli affichage visuel des pages pour la sélection (déterminé par vos enregistrements/valeur de page désirés) dans votre curseur. C'est votre première requête; il devrait retourner un seul scalaire int ou long et vous pouvez calculer ce dont vous avez besoin pour votre affichage curseur.

Les deuxièmes résultats comprennent les enregistrements réels à afficher pour une page donnée.

Étape 1 de 2 pour une page de données est d'exécuter une requête pour filtrer et classer vos résultats par une présente clé primaire dans les données que vous êtes de retour, en jetant les valeurs clés dans une table temporaire avec un AUTO_INCREMENT/IDENTITY ou le numéro de ligne pour les résultats d'une table dérivée. (Résumé: 2 champs, 1 pour la séquence/1 pour la clé primaire à joindre à l'étape 2).

L'étape 2 de 2 consiste à joindre les valeurs clés à vos tables contenant des données, en les ordonnant par la séquence déterminée à l'étape 1, en sélectionnant uniquement les lignes numérotées (ligne de début souhaitée) comme déterminé par le numéro de page et la taille de page que vous avez sélectionnés.

Une procédure stockée est fortement conseillée pour conserver les données sur le serveur pendant cette opération pendant que vous devez examiner plus de données que vous ne souhaitez vraiment ramener pour optimiser la bande passante.

+0

Super, c'est à peu près ce que j'avais à l'esprit, je voulais m'assurer que je ne manquais pas quelque chose. Ce que j'ai fini par faire est de changer la première partie. Au lieu de retourner simplement un scalaire, je retourne chaque entrée pageth.Ainsi, le nombre de lignes renvoyées par la première requête est le nombre de pages, et j'obtiens aussi les étiquettes 'gran-grandma' souhaitées en une seule requête. Il est bon d'avoir une indication de l'emplacement du fichier avant de devoir charger toutes les données de la page. – NickHalden