Version imprimable
Bonjour
J'ai installé l'extension pour utiliser la fonction connectby.
J'ai aussi testé l'exemple figurant dans la doc (cf. test_connectby.png ci-joint).
Je n'arrive pas à expliquer le résultat.
Pourquoi :
- row1, row3 et row7 n'y figurent pas
- le parent_keyid de row2 est <null> et non 'row1' ?
Merci d'avance de votre aide
Bonjour
Est-ce que quelqu'un arrive à expliquer le résultat ?
S'agit-il d'un bug ?
Merci
Bonjour,
Pour le problème spécifique à ce package aucune idée.
Par contre vous pouvez arrivé à un résultat identique en utilisant une CTE / requete recursive :http://sqlpro.developpez.com/cours/s...te-recursives/
CONECT BY est une merde imbitable qu'Oracle à finit par abandonné au profit de la norme SQL qui précise comment faire des requêtes récursives avec des CTE.
À me lire : http://sqlpro.developpez.com/cours/s...te-recursives/
L'utilisation d'une extension propriétaire d'Oracle sur une base PostGreSQL dont le maniement est connu pour être particulièrement anti-performant et qui plus est, doté d'une syntaxe perverse, relève du pure masochisme !
Préférez aller vous défouler dans une boite échangiste cuir !!! ;-)
A +
Le CONNECT BY d'Oracle rend de fiers services depuis au moins 20 ans à ceux qui se sont donné la peine de le comprendre, et il n'est absolument pas abandonné.Citation:
Envoyé par SQLpro
Tu oublie qu'il n'est pas capable de faire des requêtes récursives dans des graphes; Il sert tout juste aux arborescences !
Avec une syntaxe propriétaire imbitable que le comité de normalisation du SQL a rejeté dans la norme SQL:1999 c'est à dire il y a 13 ans !!! 'entre nous sache que le rapporteur du comité de normalisation de SQL est Jim Melton et qu'il est aussi le principal conseillé technique d'Oracle !!!!!!!!!
Je sais que tu aimes bien ton Oracle, mais faut pas pousser !!!
A +
Je sais que tu aimes bien taper sur Oracle, mais faut pas pousser !
Je ne dis pas que le CONNECT BY est parfait ; il a sans doute des défauts, et indubitablement des insuffisances.
Encore faut-il l'attaquer avec des arguments pertinents.
Imbitable ? Comme tout ce qui n'est pas de compréhension immédiate, et demande un peu d'effort. Le SQL est plein de choses imbitables si tu veux aller par là.
Syntaxe propriétaire ? En toute généralité, c'est l'argument vide par excellence. Mais quand on ajoute que le CONNECT BY est apparu avant toute norme SQL, comment voudrais-tu qu'il s'y conformât ?
En tout cas c'est un point noir connu depuis longtemps chez oracle. Même lorsque la norme sortait des choses nouvelles; Oracle implémentait autrement, sans doute du fait de l'égo surdimensionné du sieur Ellison !Citation:
Envoyé par Pomalaix
Aux gens qui lui reprochait cela, Larry répondait invariablement... Le SQL, c'est moi !
Affligeant... Heureusement depuis l'an 2000, cette politique a changé.
Mais alors comment expliquer pourquoi IBM DB2 qui proposait des avancées dans SQL et les implémentait dans DB2, avant que le comité de normalisation statue dessus les voyait quasiment systématiquement retenues ?Citation:
Mais quand on ajoute que le CONNECT BY est apparu avant toute norme SQL, comment voudrais-tu qu'il s'y conformât ?
L'explication est en fait assez simple. La norme est faite par les industriels et les discussions s'établissent régulièrement (tables rondes à l'époque mensuelles). Chacun montrait le travail et cours, ce qui orientait le travail des autres.
Encore une fois l'égo de Larry Ellison a fait que l'on a préféré faire du proprio merdique plutôt que de se fondre dans le moule commun... À l'époque ça a été bénéfique parce que cela empêchait les gens de partir d'Oracle (trop de récritures de requêtes). Maintenant c'est l'inverse... Pourquoi investir dans du cher et du complexe ???
NOTA : à l'époque de l'apparition du CONNECT BY / PRIOR (dans les années 90) il y avait déjà des discussions sur les CTE et le récursivité... et si mes souvenirs sont exacts c'est même Jim Melton qui a demandé a ce que l'on rajoute à la norme les options DEPTH FIRST BY ... et BREADTH FIRTS BY ... pour la faire ressembler à leur truc...
A +