Discussion :

[legroschat]

Hello

J' ai un problème avec un prog PL/SQL existant qui va traiter 3 types de noeuds XML.
Je vai appeller ces noeuds A,B et C;ceux ci sont stockés dans 3 tables différentes disons T_A,T_B et T_C.
En terme de structure XML on a ce qui suit
A(1,N)
|
+----B (0,N)
......|
......+-----C(1N)
Un fichier aura N noeuds A , chaque noeud A aura entre 0 et N noeuds B
et chaque noeud B aura au moins un noeud C.

Le but final est d' insérer dans une table d analyse T_X une entree par noeud C ou A si noeud A sans noeud enfant.
Les fonctions de lecture des noeuds sont prêtes et tous les types sont dans leurs tables respectives;
Le programme existant ne traite que les noeuds de type A dans un curseur;
Je dois faire le necessaire pour traiter les types B et C ;
avoir une ligne en T_X par occurence en T_C ou A si noeud A sans enfant.

J' ai un doute sur la démarche a adopter; curseurs imbriqués ou un gros insert , ou autre?

Merci d'avance!

[escartefigue]

Bonjour,

Tout simplement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
INSERT INTO T_X
      (Col01,
       Col02,
       ...,
       Coln) 
SELECT TA.Col1                           
     , TA.Col2                             
     , TB.Colp                               
     , TC.Colx
     , TC.Coly                             
FROM Table_A TA                                 
LEFT JOIN TableB TB                            
     INNER JOIN TableC TC                      
        ON TC.IdentB=TB.Ident               
  ON TB.IdantA=TA.ident

[legroschat]

Super merci d'avoir répondu aussi vite, ça marche du tonnerre;
Un dernier point sachant que la table d' analyse demandera un certain nombre de sous requêtes ;
genre prendre le champ table_O.X ou alors table_P.X selon resultat d un substr en table C
et ce pour chaque entrée de la table C ,
est ce que tu me conseilles de rester avec cet insert , ou de revenir a mon idée de base avec curseurs imbriques ?

[al1_24]

Une requête bien conçue sera dans la majorité des cas plus efficace qu'un procédure avec multiples boucles et curseurs.
A partir de la requête, l'optimiseur choisira les index les plus pertinents et l’organisation du parcours des tables la plus efficace, ce que ne saura pas toujours faire le développeur