Normalement, ils sont à éviter, mais la fonctionnalité est là pour une raison et il y a des moments pour les utiliser. Je dirais que plus de 90 % des curseurs que j'ai vus ne sont pas nécessaires. Si vous les utilisez pour des opérations CRUD, cela peut presque toujours être refait de manière basée sur un ensemble. J'ai souvent vu des gens utiliser des curseurs pour cela parce qu'ils ne savent pas comment utiliser des jointures dans une mise à jour ou une suppression ou qu'ils peuvent utiliser une instruction select au lieu d'une clause values dans une insertion. Une autre utilisation inutile lorsque les gens pensent en avoir besoin pour un traitement légèrement plus complexe qui pourrait en fait être facilement géré avec une instruction case.
Les curseurs sont parfois plus rapides pour calculer quelque chose comme un total cumulé.
Les curseurs sont également pratiques pour plusieurs exécutions d'une procédure stockée configurée pour gérer une seule valeur d'entrée à la fois. Je n'utilise pas cette fonctionnalité pour exécuter des procs stockés par l'utilisateur (sauf si je sais que je vais toucher un très petit ensemble de données) mais c'est très pratique pour les administrateurs de base de données lorsqu'ils ont besoin d'exécuter des procs système sur plusieurs tables.
Si vous créez des e-mails dans SQl (ce n'est pas le meilleur endroit pour le faire, mais dans certains systèmes, c'est là qu'ils le font) et que vous ne voulez pas que tout le public de l'e-mail voie les autres personnes de la liste ou que vous souhaitiez personnaliser chacun email avec des informations sur le destinataire, les curseurs sont la voie à suivre.
Des curseurs ou des boucles peuvent également être utilisés pour traiter des lots d'enregistrements si l'insertion/mise à jour/suppression basée sur un ensemble prend trop de temps et verrouille les tables. C'est une sorte d'hybride entre les curseurs et la solution basée sur les ensembles et c'est souvent la meilleure pour les changements importants sur les systèmes de production.
