L'explication dans la réponse de Krokodilko est tout simplement fausse. Vous pouvez ignorer la marque "Réponse correcte" et les nombreux votes positifs, c'est toujours faux. Il est intéressant qu'il ait laissé comme exercice exactement le cas qui prouve que l'explication est fausse.
A CONNECT BY la requête ne fonctionne pas "comme si" les nouvelles tables (ou les nouveaux ensembles de lignes de sortie de SELECT déclarations, de toute façon) sont générés à chaque étape. C'est l'erreur dans l'argument.
Au contraire, il n'y en a qu'un un ensemble de lignes généré globalement (à toutes les étapes). Il est vrai que de nouvelles lignes sont ajoutées en fonction des lignes générées à l'étape précédente ; mais le jeu de lignes lui-même est un, et en croissance, pas des jeux de lignes séparés.
Ceci est particulièrement pertinent en ce qui concerne ROWNUM . ROWNUM est affecté à des lignes dans un ensemble de lignes "résultat" unique, en commençant par 1. Dans un CONNECT BY requête, il n'y a qu'un seul jeu de lignes et ROWNUM va de 1 à n dans une séquence croissante.
Si la réponse de Krokodilko était correcte, alors ROWNUM redémarrerait à 1 à chaque étape. Ce n'est clairement pas le cas :essayons sur une requête hiérarchique "standard".
select empno, ename, mgr, level, rownum
from scott.emp
start with mgr is null
connect by prior empno = mgr
;
EMPNO ENAME MGR LEVEL ROWNUM
---------- ---------- ---------- ---------- ----------
7839 KING 1 1
7566 JONES 7839 2 2
7788 SCOTT 7566 3 3
7876 ADAMS 7788 4 4
7902 FORD 7566 3 5
7369 SMITH 7902 4 6
7698 BLAKE 7839 2 7
7499 ALLEN 7698 3 8
7521 WARD 7698 3 9
7654 MARTIN 7698 3 10
7844 TURNER 7698 3 11
7900 JAMES 7698 3 12
7782 CLARK 7839 2 13
7934 MILLER 7782 3 14
