Quelle est la lenteur des curseurs et quelles seraient les meilleures alternatives?

Question

J'ai lu que les curseurs sont assez slow et il faut le faire, sauf si les options les évitent. J'essaie d'optimiser mes procédures stockées et l'une d'elles utilise un curseur. Il est fréquemment appelé par mon application et avec beaucoup d'utilisateurs (20000) et les lignes à mettre à jour. Je pensais que je devrais peut-être utiliser autre chose comme une alternative. Tout ce que j'essaie de faire ou de vouloir, c'est d'obtenir une liste d'enregistrements, puis d'opérer selon la valeur de chaque ligne. Donc, pour nous dire par exemple -

Employee - Id,Name,BenefitId,StartDate,EndDate 

donc basée sur benefitId je dois faire le calcul différent en utilisant les dates entre StartDate et EndDate et mettre à jour les détails des employés. Je fais juste cet exemple artificiel pour donner une idée de ma situation.

Que pensez-vous de cela? Existe-t-il de meilleures alternatives pour les curseurs comme les tables temporaires ou les fonctions définies par l'utilisateur? Quand devriez-vous vraiment opter pour eux ou devrions-nous ne jamais utiliser des curseurs? Merci à tous pour leur aide.

Answer 1

J'ai changé sur les curseurs et déplacé de plus de 24 heures de temps de traitement à moins d'une minute.

Pour vous aider à voir comment résoudre votre proc avec la logique ensembliste, lisez ceci: http://wiki.lessthandot.com/index.php/Cursors_and_How_to_Avoid_Them

Answer 2

J'ai une fois changé une procédure stockée de curseurs à la logique basée sur l'ensemble. Le temps de fonctionnement est passé de 8 heures à 22 secondes. C'est le genre de différence dont nous parlons. Au lieu de prendre un enregistrement différent à la fois, utilisez plusieurs passages sur les données. Mettez à jour et définissez field1 = A où field2 est X, puis mettez à jour et définissez field1 = B où field2 est Y, etc.

Answer 3

Un curseur effectue un traitement ligne par ligne ou "Row by Agonizing Row" si votre nom est Jeff Moden.

Ceci est juste one example de la façon de faire la programmation SQL à base de set par opposition à RBAR, mais cela dépend finalement de ce que fait votre curseur.

En outre, un coup d'oeil à ce sur StackOverflow:

RBAR vs. Set based programming for SQL

Answer 4

Tout d'abord, il semble que vous essayez de mélanger la logique métier dans vos procs stockés. C'est généralement quelque chose que vous voulez éviter. Une meilleure solution serait d'avoir une couche intermédiaire qui encapsule cette logique métier. De cette façon, votre couche de données reste purement des données.

Pour répondre à votre question initiale, cela dépend vraiment de ce que vous utilisez pour les curseurs. Dans certains cas, vous pouvez utiliser une variable de table ou une table temporaire. Vous devez vous rappeler de libérer des tables temporaires, alors je suggère d'utiliser des variables de table autant que possible. Parfois, cependant, il n'y a aucun moyen d'utiliser des curseurs. Peut-être que les DBA d'origine n'ont pas assez normalisé (ou trop normalisé) et vous êtes obligé d'utiliser un curseur pour traverser plusieurs tables sans aucune relation de clé étrangère.