|
|
|
нестандартные рекурсивные CTE - почему ТАК?
|
|||
|---|---|---|---|
|
#18+
Теоретически ничто в рекурсивном CTE не запрещает иметь более 2 субзапросов. Попробовал использовать это - и наткнулся на непонимание, как вообще выполняется CTE. В частности, я не понимаю логики порядка исполнения. Вот модель: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. В документации ничего вменяемого не нашёл... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.09.2018, 13:22 |
|
||
|
нестандартные рекурсивные CTE - почему ТАК?
|
|||
|---|---|---|---|
|
#18+
PS. Это я ещё не говорил о случае, когда первый субзапрос - выборка из таблицы, а не статика... и уж совсем тёмный лес, когда перемешаны UNION ALL и UNION DISTINCT... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.09.2018, 13:24 |
|
||
|
нестандартные рекурсивные CTE - почему ТАК?
|
|||
|---|---|---|---|
|
#18+
Логика следующая: -) создается исходный набор строк S0. В примере это будет одна строка (1,2) -) на основании S0 создается новый набор строк S1 - (2,4),(3,15) -) на основании S1 создается новый набор строк S2 - (4,6),(5,35),(6,145) -) на основании S2 создается новый набор строк S3 - (7,8),(8,55) -) на основании S3 создается новый набор строк S4 - (9,75) -) слияние промежуточных наборов S0, … S4 результат чего и виден и итоговом обращении к cte В своей интерпретации, я на каждую строку предыдущего набора действовал сначала первой рекурсивной частью, потом второй. Но дока прямо говорит, что при наличии нескольких блоков в рекурсивной части порядок их применения не определен. Each iteration of the recursive part operates only on the rows produced by the previous iteration. If the recursive part has multiple query blocks, iterations of each query block are scheduled in unspecified order, and each query block operates on rows that have been produced either by its previous iteration or by other query blocks since that previous iteration's end. Глядя на первый пример, можно предположить, что: а) сначала были сформированы наборы S0: (1,2) S1: (2,4) S2: (3,6) S3: (4,8) путем применения первой части рекурсивного запроса б) затем они дополнялись: к S1 + (5,15) к S2 + (6,35) к S3 + (7,55) сформирован S4 (8,75) в) вернулись назад и дополняем наборы на основании новых строк, в итоге добавится только одна строка в S2 (9,145). Вывод: использование пользовательских переменных в данном контексте некорректно, так как результат будет зависеть от плана выполнения запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2018, 00:22 |
|
||
|
нестандартные рекурсивные CTE - почему ТАК?
|
|||
|---|---|---|---|
|
#18+
retvizanВывод: использование пользовательских переменных в данном контексте некорректно, так как результат будет зависеть от плана выполнения запроса.Ну тут скорее наоборот, поскольку переменная используется именно для определения реального порядка выполнения. retvizan each query block operates on rows that have been produced either by its previous iteration or by other query blocks since that previous iteration's end . Вот над этой фразой надо долго думать... пока навскидку мне кажется, что тут может быть потенция потери записей, потому что блоки обрабатываются в общем случае последовательно... т.е. теоретически, если верить ЭТОЙ фразе, то записи, произведённые последним блоком на предыдущей итерации, не будут обрабатываться другими блоками на текущей итерации, потому как не подпадают ни под одно из двух данных тут определений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2018, 08:01 |
|
||
|
нестандартные рекурсивные CTE - почему ТАК?
|
|||
|---|---|---|---|
|
#18+
Akinaretvizan each query block operates on rows that have been produced either by its previous iteration or by other query blocks since that previous iteration's end . Вот над этой фразой надо долго думать... пока навскидку мне кажется, что тут может быть потенция потери записей, потому что блоки обрабатываются в общем случае последовательно... т.е. теоретически, если верить ЭТОЙ фразе, то записи, произведённые последним блоком на предыдущей итерации, не будут обрабатываться другими блоками на текущей итерации, потому как не подпадают ни под одно из двух данных тут определений. Я перевел эту фразу как: каждый блок запроса работает со строками, которые были созданы его предыдущей итерацией (т.е. итерацией конкретного блока) или другими блоками запроса с момента окончания предыдущей итерации (итерации того самого конкретного блока) . Т.е. при наличии более одного блока каждый может вызываться несколько раз, чтобы обработать все строки из предыдущего промежуточного набора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2018, 11:21 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39706088&tid=1829595]: |
0ms |
get settings: |
12ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
41ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
| others: | 244ms |
| total: | 390ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...