Discussion :

[ekremyilmaz]

Bonjour,

juste une petite question :
Oracle permet de gérer le concept de requêtes récursives, à l'aide des clauses suivantes : start-with et connect by

est-ce que c'est une bonne chose ?
En gros, est-ce que ça plombe les perfs ?

Etant donné que j'ai au moins 170000 enregistrements ? Est-ce une bonne chose.

Vous me direz vaut mieux utiliser ça que faire des sous-requetes ou des auto jointures.....

Ma table a beaucoup de colonne.

pour faire simple j'ai

operation_id,-----nom, ------operation_precedent
1---------"operation1"---------null
2---------"operation2"--------- 1
3 --------- "operation3"--------- 2
4 --------- "operation4" --------- null
5 ---------"operation5"--------- 4


Je dois récupérer chaque chaine.

En gros, j'aurai les chaines suivantes : 3->2->1 et 5->4.

J'ai pas envie de savoir la requête, je la ferai en m'aidant des docs, mais j'aimerai juste savoir, si utiliser connect by est une bonne chose pour les perfs ?

ou bien, y -a t-il un autre moyen ?

Ma question : est-ce que connect by est conseillé ?

merci

[Doracle]

Le principe des requêtes hiérarchiques (et non pas récursives) est que justement il va parcourir tous les tuples de ta table et chercher a faire uné égalité entre ta clef étrangère et ta clef primaire. Comme le principe des jointures, sauf que là forcément c'est une "self-join", que tu peux traduire par "jointure sur elle-même".
Dans ton cas tu nous montres un échantillon des tuples de la table ou le contenu total mais seulement certaines colonnes ?

Car si tu as peu de lignes, il n'y aura pas de souci. Par contre c'est vrai que le récursif est souvent gourmand en ressources. Mais le problème sera le même si tu fais le traitement dans ton code. Par contre j'avoue ne pas connaître d'autres alternatives efficaces ... Mais je te conseillerai quand même le CONNECT BY.

Au niveau de la syntaxe :

Code :

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

1
2
3
4
5
 
SELECT operation_id, nom, operation_precedent, LEVEL
FROM matable
START WITH operation_id=1
CONNECT BY PRIOR operation_id=operation_precedent;

START WITH indique a partir de quel moment de la table tu vas commencer le parcours récursif, ainsi tu peux générer des "arbres" restreints. CONNECT BY PRIOR indique les 2 champs en lien.
La colonne virtuelle LEVEL est intéressante, elle indique le niveau au sein de l'arbre, et donc si tu cherches a faire des manipulations c'est souvent sur cette colonne que cela se fait.

En espérant t'avoir aidé.

[SQLpro]

1) CONNECT BY / PRIOR est spécifique à Oracle et ne fait pas partie du SQL. Le langage SQL accepte les requêtes récursives avec le concept de CTE depuis la version 1999 de la norme. Voir l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/s...te-recursives/

2) si vous avez une arborescence, toute requête récursive est plus consommatrice que n'importe quel autre traitement itératif et assez mal optimisable, même avec de bons index.

3) si vous voulez des performances dans l'interrogation des arbres, optez pour une représentation de votre arborescence en mode intervallaire. Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/arborescence/

Voir aussi mon blog pour les sujet connexes !

A +

[ekremyilmaz]

Je ne montre que les tuples, car il y a beaucoup de colonne, et de toute manière, je récupérerai l'operation_id, nom et operation_precedent.


Oui merci !!!! de toute manière, je ne vois pas aussi comment faire :d à part ça !!
car si je m'amuse à traiter ça avec le code, je risque de faire plein de requête..........

et ce n'est pas dit que c'est plus optimale !

Merci en tout cas.

Est-ce possible de mettre des conditions where dans la requete que tu m'a montré ?

[ekremyilmaz]

ooo cool !!

merci, je vais lire en détail ! et si le moindre problème, je te poserai des questions.

merci !

[ekremyilmaz]

le problème avec le système à intervalle, c'est que cela me fait changer ma structure de la base et aussi mettre à jour les 200000 enregistrements avec un script (qui faut bien entendu qui soit correcte ) et cela fait aussi changer le code java pour prendre en compte ce système.

Le risque est trop important.

La question que je me pose, le connect by consomme peut etre beaucoup de ressources, mais là je l'utilise pour un batch de purge qui sera exécuté le soir (quand tout le monde fait dodo )!!

donc cela peut-il poser un souci au niveau des ressources même si on sait que personne ne travaille sur la base ??

Car actuellement, nous sommes entrain de mettre en place un système d'archivage/purge qui n'a pas été conçu lors du développement il y a 3 ans.

Il faudra archiver toutes les données actuelles, nous n'allons pas le faire tout d'un coup, ça va être lourd ! mais petit à petit (je ne connais pas encore le nombre d'enregistrements).

A terme, il y aura surement 5000 enregistrements à purger par jour/semaine (comparé à 200000 au début ).

C'est pourquoi, je me pose la question d'utiliser le connect by même si cela consomme beaucoup mais c'est pendant la nuit, (à moins qu'au matin, il n'est pas terminé )!!!

[Waldar]

Le mieux c'est encore d'essayer, il y a tant de paramètres qui rentrent en jeu sur le temps d'exécution d'une requête.

Votre table peut faire 170 000 lignes, si elle fait 3 Mo ou 2 Go ce ne sera pas la même histoire.

[ekremyilmaz]

j'ai testé ce matin sur un jeu de donnée de 2 millions d'enregistrements.

Il a mis 406s !

[ekremyilmaz]

une autre petite question,
supposé que je dois faire un insert de ces 2 millions d'enregistrements.
Car lors du processus de purge, on dois récupérer les identifiants technique des opérations et les stocker dans une table "EXTRACTION" avant de les supprimer des tables d'origines OPERATION.

Donc je fais mon select avec count by et je fais une boucle en Java sur les résultats (2 millions d'enregistrement) en faisant un insert....

for (listeresultat){
insert...
}


A votre avis, (car je ne peux pas le tester encore), le temps d'exécution des inserts avec cette boucle sera t'elle longue ?

Ensuite une fois que j'ai inséré les opérations dans la table EXTRACTION.

Je fais un delete from OPERATION where id in (select id from EXTRACTION)

J'aimerai avoir votre avis sur la durée totale :
1) select
2) insert
3) delete

[ekremyilmaz]

je pense utiliser une procedure stockée pour réaliser ce traitement, ça m'évitera de faire plusieurs aller-retour avec le serveur.

et ça risque d'être moins lourd je pense !

[Waldar]

Vous faites quoi au juste en java avec vos données ?

[ekremyilmaz]

rien !!
En gros, j'ai un batch de purge où je dois faire des contrôles java pour voir si le batch peut etre lancé ou pas, et là je lance mes requetes.....

Par contre, je viens d'apprendre que chez le client, les procédures stockées sont bannis !!

Mais ça change pas grand chose, j'ouvrirai un cursor avec jdbc où pour chaque enregistrement, je ferai un insert (dans un table) et un delete de la donnée dans la table d'origine).

En gros, je fais tout dans une boucle !!!
Et je mettrai le commit à la fin pour valider les enregistrements !!

Après moult discussion avec l'équipe, c'est la seule solution viable, en utilisant le connect by.

J'ai 1h pour la purge, sachant que pour 2 millions d'enregistermnt, j'ai mis 6min.
Je pense avec ce système gagner du temps !!

merci en tout cas pour les infos !

[Waldar]

Nul besoin de boucle alors, vous pouvez envoyer vos ordres SQL ensemblistes pour chaque étape.

[ekremyilmaz]

comment faire pour stocker dans une table (virtuelle ou temporaire) des données qu'on veut stocker temporairement ?

D'après des collègues, on peut le faire sans passer par un create table....
mais directement à partir d'une requete select into ????

j'ai vu sur le net des choses, mais j'aimerai avoir votre avis sur le sujet ?