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 cette ressource
Guide de technologie 5G pour l’entreprise
Pourquoi la 5G est-elle faite pour votre entreprise ? La 5G peut améliorer la vitesse, la fiabilité et la capacité de votre réseau, permettant ainsi une meilleure collaboration, une productivité accrue et une prise de décision plus rapide. Notre livre blanc " The Big Book of Enterprise 5G" vous fournit les informations stratégiques dont vous avez besoin pour prendre des décisions éclairées et préparer votre entreprise à prospérer dans l'ère de la 5G. Cradlepoint, part of Ericsson est le leader mondial des solutions de réseau sans fil 4G LTE et 5G fournies via le cloud. Connectez vos employés, lieux et objets avec la 4G LTE et la 5G pour un WAN sans fil d'entreprise.
