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
Prédictions 2025 des menaces persistantes avancées
L'analyse et l'évolution du paysage des menaces persistantes avancées (APT) et des conséquences sur vos infrastructures IT. Découvrez la synthèse des prédictions, tendances et recommandations pour 2025 avec les experts Kaspersky.
Les articles les plus consultés
- 10 grandes tendances Business Intelligence
- 9 défis de transformation digitale !
- ActiveViam fait travailler les data scientists et les décideurs métiers ensemble
- Stockage autonome, Evolutivité & Gestion intelligente, Pure Storage offre de nouvelles perspectives aux entreprises
- Dark Web : où sont vos données dérobées ?
Les plus consultés sur iTPro.fr
- Défis et bénéfices d’infuser l’IA dans l’analytique et la BI
- Mieux protéger l’entreprise à l’ère du travail hybride et du Cloud
- Les entreprises concentrent les investissements sur l’innovation, l’efficacité et la résilience
- L’IA profite au marché du mobile !
- La législation européenne sur l’IA entre en vigueur. Comment s’y préparer au mieux ?
