> Data > Pagination côté serveur avec SQL Server

Pagination côté serveur avec SQL Server

Data - Par iTPro.fr - Publié le 24 juin 2010
email

par Andrew Rosca - Mis en ligne le 6/07/2005 - Publié en Octobre 2004

Une procédure stockée simple vous permet de contrôler les flux de données et d'accéder à  des millions d'enregistrements

Les applications Web utilisent fréquemment la pagination d'enregistrements afin de présenter de très grandes quantités de données aux utilisateurs. Par exemple, il n'est pas rare qu'un moteur de recherche Internet retourne des dizaines de milliers de résultats en réponse à  une requête d'un utilisateur. Si le moteur renvoyait l'ensemble des résultats en une seule fois, le système destinataire serait complètement saturé. C'est pourquoi la pagination décompose les données en blocs de taille fixe rendant possible la gestion des résultats et réduisant la quantité d'informations transférées en une seule fois du serveur vers le client ...L'application ne propose que quelques enregistrements à  la fois aux utilisateurs, en commençant de préférence par les informations les plus pertinentes. Non seulement la pagination facilite la compréhension et la consultation des données, mais elle améliore également les performances de l'application, car la récupération et l'affichage de volumes élevés d'informations créent une charge inutile qui peut ralentir votre système. Si ce dernier pagine les enregistrements correctement, les utilisateurs d'un moteur de recherche n'auront vraisemblablement pas besoin de consulter plus d'une ou deux pages de résultats.
Malheureusement, de nombreux programmeurs n'ont pas conscience de certains aspects importants de la pagination sur le plan des performances. Dans un environnement IIS et SQL Server classique, la méthode la plus fréquente de mise en oeuvre de la pagination consiste à  utiliser les fonctionnalités de pagination de l'objet ADO Recordset standard, notamment les propriétés AbsolutePage, PageSize et PageCount. Pour les volumes de données relativement faibles (entre quelques dizaines et quelques centaines d'enregistrements), ces fonctionnalités sont parfaitement appropriées et la charge qu'elles génèrent n'affecte pas sensiblement les performances. Toutefois, à  mesure que le nombre d'enregistrements augmente, cette technique perd en efficacité et entraîne une baisse sensible des performances de l'application.
Dans les applications gérant des volumes importants de données, par exemple une application d'approvisionnement qui affiche des nombres élevés de commandes, un site de rencontres gérant des milliers d'utilisateurs ou un site de commerce électronique qui affiche des centaines de produits en réponse à  une recherche d'un utilisateur, vous avez besoin de techniques de pagination côté serveur sophistiquées. Cet article présente un exemple simple de technique de codage que j'utilise pour des tables contenant plusieurs millions d'enregistrements.

Pagination côté serveur avec SQL Server

Les problèmes de pagination rencontrés
lorsque vous accédez à  des nombres
élevés d’enregistrements sont liés
à  la manière dont ADO gère les données.
Pour récupérer des informations
dans la base de données, l’infrastructure
ADO a besoin d’un pointeur vers
ces données. Celui-ci, appelé curseur,
permet au client (par ex., l’environnement
Active Server Pages (ASP)) d’extraire
les enregistrements un par un.
L’objet ADO Recordset prend en
charge deux types de curseurs : côté
serveur (par défaut) et côté client.
L’application peut laisser toutes les
données sur le serveur SQL Server et
utiliser un curseur côté serveur pour
récupérer séquentiellement les enregistrements
au moment voulu. Elle
peut également transférer toutes les
données vers le client et se servir du
curseur côté client pour lire les données
par enregistrement à  partir de la
mémoire tampon du client. Si vous
avez besoin d’utiliser ou d’afficher seulement
quelques-uns des enregistrements
retournés par une requête,
comme c’est le cas dans un scénario de
pagination, un curseur côté serveur est
plus efficace car SQL Server transfère
uniquement la page requise au client
et conserve les autres enregistrements
sur le serveur de base de données. Un
curseur côté serveur limite les données
envoyées sur le client aux 20 ou
30 enregistrements qui constituent
une page individuelle.
Néanmoins, pour employer certaines
fonctionnalités de pagination de
l’objet Recordset (par ex., PageCount),
un curseur côté client est nécessaire.
Pour indiquer à  ADO d’utiliser ce type
de curseur, vous devez modifier de
adUseServer en adUseClient la valeur
de la propriété ClientLocation de l’objet
Recordset. Le code Visual Basic du
listing 1 illustre comment utiliser un
objet Recordset respectivement avec un curseur côté client et un curseur côté serveur. Le fait d’affecter
la valeur AdUseClient à  la propriété ClientLocation
provoque le transfert vers le client de tous les enregistrements
retournés par une requête, de sorte que l’objet
Recordset peut déterminer le nombre total de pages nécessaire
pour les données.
Par exemple, imaginez que vous exécutez une requête
qui renvoie 5000 enregistrements de la base de données. Si
l’application pagine ces enregistrements en utilisant des
pages de 20 à  30 enregistrements chacune et si l’utilisateur
examine la page 1, l’application doit transférer uniquement
les 20 premiers enregistrements au client. Lorsque l’utilisateur
passe à  la deuxième page, l’application transfère uniquement
les enregistrements 21 à  40. Toutefois, lorsque vous
employez un curseur côté client, ADO transfère les 5000 enregistrements
chaque fois que l’utilisateur consulte les données,
même s’il n’a besoin que de 20 enregistrements. Ce
transfert complet entraîne des retards sensibles et gênants,
ainsi qu’une baisse sérieuse des performances si le nombre
d’enregistrements est extrêmement élevé.

Téléchargez gratuitement cette ressource

Guide de Cloud Privé Hébergé

Guide de Cloud Privé Hébergé

Comment permettre aux entreprises de se focaliser sur leur cœur de métier, de gagner en agilité, réactivité et résilience en s’appuyant sur un socle informatique performant, évolutif et sécurisé ? Découvrez les avantages des solutions de Cloud Privé hébergé de la CPEM.

Data - Par iTPro.fr - Publié le 24 juin 2010