PL/SQL, curseurs [Oracle] - SQL/NoSQL - Programmation
Marsh Posté le 16-06-2015 à 10:48:47
Salut
J'arrive apres la guerre, mais c'est relativement typique des gens qui ont appris a programmer en procedural et ne comprennent pas les avantages de l'ensembliste dans certains cas.
99% de chances que ca aille plus vite une fois reecrit comme tu le suggeres.
A+
Marsh Posté le 16-06-2015 à 11:54:53
Ok, merci pour ta réponse.
En tous cas, si ça n'est pas plus rapide, je pense que ça sera plus lisible et plus facilement maintenable...
Reste à convaincre que ce n'est pas une lubie d'un nouveau qui veut faire à sa façon (c'est un peu ce qu'on m'a dit quand j'ai posé des questions sur cette façon de faire).
Marsh Posté le 19-05-2015 à 20:33:40
Bonjour,
Je suis en train de découvrir une base de données dans le cadre d'un nouveau boulot. Je constate qu'il y a beaucoup de packages qui contiennent des procédures construites sous cette forme :
Déclaration d'un curseur C1 qui récupère certains clients sur quelques critères (date de création, dernier article acheté par exemple)
puis
Déclaration d'un curseur C2 avec en paramètre l'id_client qui fait un "count(*)" sur d'autres critères (date de dernier passage en magasin datant de moins d'un mois, panier moyen supérieur à 50€)
Déclaration d'un curseur C3 avec en paramètre l'id_client qui fait un "count(*)" sur d'autres critères (premier achat datant de plus de 5 ans, segmentation de moins de 3 mois)
(dans certaines procédures, il peut y avoir jusqu'à 10 de ces curseurs)
et finalement
une boucle sur le curseur C1, qui "fetch" le résultat des curseurs C2, C3... dans des variables V1, V2... en leur passant en paramètre l'id_client courant, et un test qui vérifie que si ces variables sont bien à 0, on garde l'id_client (que l'on insère dans un table à part pour un traitement ultérieur), et sinon on ne fait rien de l'id_client sélectionné dans le curseur C1.
Etant plutôt partisan des traitements ensemblistes, mais avant de réécrire ces procédures, je me demandais si quelqu'un voyait un intérêt à ce type de traitement ? La personne en charge de ces développements m'a dit que c'était par soucis de performance, mais j'ai du mal à voir comment ça peut être plus rapide qu'une requête "normale" qui ferait l'INSERT en prenant en compte tous les critères directement.