Qu’est qu’un curseur ?
Les opérations réalisées dans une base de données relationnelle s'exécutent sur un ensemble complet de lignes. L'ensemble de lignes retourné par une instruction SELECT contient toutes les lignes satisfaisant aux conditions de la clause WHERE de l'instruction. Cet ensemble complet de lignes retournées par l'instruction est appelé ensemble de résultats. Les applications, notamment celles qui sont interactives et en ligne, ne peuvent pas toujours fonctionner efficacement avec l'ensemble des résultats en tant qu'unité. Ces applications ont besoin d'un mécanisme leur permettant de travailler avec une seule ligne ou avec un petit bloc de lignes à la fois. Les curseurs sont une extension des ensembles de résultats et fournissent ce mécanisme.
Un curseur est implémenté par une bibliothèque de curseurs. Une bibliothèque de curseurs est un logiciel, souvent implémenté dans le cadre d’un système de base de données ou d’une API d’accès aux données, qui est utilisée pour gérer les attributs des données retournées à partir d’une source de données (jeu de résultats). Ces attributs incluent la gestion de l’accès concurrentiel, la position dans le jeu de résultats, le nombre de lignes retournées et si vous pouvez avancer ou reculer (ou les deux) dans le jeu de résultats (défilement).
Un curseur effectue le suivi de la position dans le jeu de résultats et vous permet d’effectuer plusieurs opérations ligne par ligne sur un jeu de résultats, avec ou sans retour à la table d’origine. En d’autres termes, les curseurs retournent conceptuellement un jeu de résultats basé sur des tables au sein des bases de données. Le curseur est ainsi nommé, car il indique la position actuelle dans le jeu de résultats, tout comme le curseur sur un écran d’ordinateur indique la position actuelle.
Il est important de se familiariser avec le concept de curseurs avant de passer à l’apprentissage des spécificités de leur utilisation dans ADO.
À l’aide de curseurs, vous pouvez :
Spécifier le positionnement sur des lignes spécifiques dans le jeu de résultats.
Récupérer une ligne ou un bloc de lignes en fonction de la position actuelle du jeu de résultats.
Modifier les données dans les lignes à la position actuelle dans le jeu de résultats.
Définir différents niveaux de sensibilité aux modifications de données apportées par d’autres utilisateurs.
Par exemple, considérer une application qui affiche une liste de produits disponibles pour un acheteur potentiel. L’acheteur fait défiler la liste pour afficher les détails et les coûts du produit, puis sélectionne un produit à acheter. Le défilement et la sélection supplémentaires se produisent pour le reste de la liste. En ce qui concerne l’acheteur, les produits apparaissent un par un, mais l’application utilise un curseur défilant pour parcourir le jeu de résultats vers le haut et le bas.
Vous pouvez utiliser les curseurs de différentes manières :
Sans lignes du tout.
Avec une partie ou l’ensemble des lignes d’une seule table.
Avec une partie ou l’ensemble des lignes des tables jointes logiquement.
En lecture seule ou pouvant être mise à jour au niveau du curseur ou du champ.
En tant que défilement avant uniquement ou entièrement défilant.
Avec l’ensemble de touches de curseur situé sur le serveur.
Sensibles aux modifications de table sous-jacentes provoquées par d’autres applications (telles que l’appartenance, le tri, les insertions, les mises à jour et les suppressions).
Existants sur le serveur ou le client.
Les curseurs en lecture seule aident les utilisateurs à parcourir le jeu de résultats et les curseurs en lecture/écriture peuvent implémenter des mises à jour de lignes individuelles. Les curseurs complexes peuvent être définis avec des jeux de clés qui pointent vers des lignes de table de base. Bien que certains curseurs soient en lecture seule dans une direction vers l’avant, d’autres peuvent se déplacer vers l’arrière et fournir une actualisation dynamique du jeu de résultats en fonction des modifications apportées par d’autres applications à la base de données.
Toutes les applications n’ont pas besoin d’utiliser des curseurs pour accéder aux données ou les mettre à jour. Certaines requêtes ne nécessitent simplement pas de mise à jour directe de ligne à l’aide d’un curseur. Les curseurs doivent être l’une des dernières techniques que vous choisissez de récupérer des données, puis vous devez choisir le curseur d’impact le plus bas possible. Lorsque vous créez un jeu de résultats à l’aide d’une procédure stockée, le jeu de résultats n’est pas modifiable à l’aide des méthodes de modification ou de mise à jour du curseur.
Accès concurrentiel
Dans certaines applications multiutilisateurs, il est très important que les données présentées à l’utilisateur final soient aussi actuelles que possible. Un exemple classique de ce système est un système de réservation de compagnies aériennes, où de nombreux utilisateurs peuvent prétendre au même siège sur un vol donné (et par conséquent, un seul enregistrement). Dans un cas comme celui-ci, la conception de l’application doit gérer les opérations simultanées sur un seul enregistrement.
Dans d’autres applications, la concurrence n’est pas aussi importante. Dans ce cas, les dépenses liées à la conservation des données actuelles à tout moment ne peuvent pas être justifiées.
Position
Un curseur effectue également le suivi de la position actuelle dans un jeu de résultats. Considérez la position du curseur comme un pointeur vers l’enregistrement actif, similaire à la façon dont un index de tableau pointe vers la valeur à cet emplacement particulier dans le tableau.
Capacité de défilement
Le type de curseur utilisé par votre application affecte également la possibilité d’avancer et de revenir à travers les lignes d’un jeu de résultats ; il s’agit parfois de la possibilité de défilement. La possibilité d’avancer et de reculer par le biais d’un jeu de résultats ajoute à la complexité du curseur et est donc plus coûteuse à implémenter. Pour cette raison, vous devez demander un curseur avec cette fonctionnalité uniquement si nécessaire.