Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
861 connectés 

  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  [Oracle] PL/SQL, curseurs

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[Oracle] PL/SQL, curseurs

n°2258408
Tibar
Posté le 19-05-2015 à 20:33:40  profilanswer
 

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.

mood
Publicité
Posté le 19-05-2015 à 20:33:40  profilanswer
 

n°2260005
Tibar
Posté le 09-06-2015 à 17:51:42  profilanswer
 

Ce n'est pas clair ou personne n'a un avis tranché ?

n°2260414
lasnoufle
La seule et unique!
Posté le 16-06-2015 à 10:48:47  profilanswer
 

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+


---------------
C'était vraiment très intéressant.
n°2260429
Tibar
Posté le 16-06-2015 à 11:54:53  profilanswer
 

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).


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  [Oracle] PL/SQL, curseurs

 

Sujets relatifs
[SQL/PLSQL] problème sur requête[VBScript] Connexion oracle en sysdba
POWERSHELL ORACLELecture Flux XML, Doublon et ressources SQL
[SQL/SQL Server] Date maximale pour calcul suivant une cat/agent[Réglé] [SQL] [ORACLE] Tri / regroupement "cyclique" ?
[SQL] Aide requête avec enregistrement facultatifRequête SQL Update dans PHP
Plus de sujets relatifs à : [Oracle] PL/SQL, curseurs


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR