|
|
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
HelpMePlsRegular expression - было бы хорошо добавить. или не было заметок?Так регулярки - это не SQL, получается отклонение от темы. Материалов масса, вплоть до оракловых White Paper - Introducing Oracle Regular Expressions . Интереснее было бы написать сравнение оракловой реализации скажем, с perl, чтоб показать ограниченность первой. Для этого легко можно подобрать с десяток реальных задач даже только с этого форума. Я как-то публиковал краткий обзор Evolution of regular expressions . Дальше развивать тему не особо интересно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 21:12 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, 83 страница: Например, имеет информация по продажам за 12 месяцев и надо для каждого месяца отношение объема продаж к значению для первого месяца. ... select id, value, value / min(value) over() ratio from t может first_value(value) over() ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 09:54 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, Почту отправить не могу, поэтому пишу отзыв сюда. 1) Отличная глава про джоины! К стыду своему узнал кое-что новенькое в такой, скажем, базовой теме. А остальное отлично разложено по полочкам, не грех повторить и уложить в голове лишний раз. 2) А вот самые интересные для меня главы про model и match_recogzine показались слабее. Я не мастер model, но не нашел почти ничего нового и полезного по сравнению со старенькой статьей на Хабре ( https://habrahabr.ru/post/101003/), которая, как мне кажется, более доступна людям, не знакомых с данным оператором. 3) Почему мне так кажется? Потому что к главе про match_recogzine я подошел абсолютно нулевым, в надежде первый раз узнать про данный чудо-оператор, и... ничего не понял. Совсем. Ну, первая моя мысль, что наверно я просто туплю, но, как оказалось, достаточно быстро нагугливается переведенная статья Кайта ( http://www.fors.ru/upload/magazine/09/http_text/fors_article_kyte.html), которая разбирает похожий пример, но делает это гораздо, гораздо понятней и наглядней. После данной статьи я снова перечитал главу из книги, и пришел к тому же выводу что и для главы про model: не знакомому понятно сложно, а знакомый не найдет много нового и полезного. В общем, хочется больше поясняющего текста, более плавный переход от простого к сложному. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 10:45 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
moishamiem2) А вот самые интересные для меня главы про model и match_recogzine показались слабее. Я не мастер model, но не нашел почти ничего нового и полезного по сравнению со старенькой статьей на Хабре ( https://habrahabr.ru/post/101003/), которая, как мне кажется, более доступна людям, не знакомых с данным оператором.Ну давай разложим по полочкам. Начнем с хабровской статьи. Прежде всего неверно отражена суть с самого старта Модель для "подсчёт промежуточных итогов по подгруппам, ..., сложное форматирование строк"?Далее: Аналитические функции внутри правил запрещены.Да? Применение конструкции MODEL запрещает использовать агрегатные функции внутри других блоков SELECT.Что? Важно знать, что UPSERT ALL работает...Не так он работает. Директива AUTOMATIC ORDER используется для того, чтобы p1 и p2 считались по очереди для текущего отрезка.Категорически неверно. Правила всегда вычисляются по столбцам а не строкам. С производительностью всё просто.Только написана полная чепуха. Стоит заметить, что хабровская аудитория отлично проглотила статью, а другого я от неё и не ожидал. Я ничего не увидел про ссылочные (reference) модели, про несходимые модели (does not converge) и множество прочих деталей от ограничений на правила до особенностей итеративных моделей. Анализ производительности нельзя воспринимать всерьез. moishamiem3) Почему мне так кажется? Потому что к главе про match_recogzine я подошел абсолютно нулевым, в надежде первый раз узнать про данный чудо-оператор, и... ничего не понял. Совсем. Ну, первая моя мысль, что наверно я просто туплю, но, как оказалось, достаточно быстро нагугливается переведенная статья Кайта ( http://www.fors.ru/upload/magazine/09/http_text/fors_article_kyte.html), которая разбирает похожий пример, но делает это гораздо, гораздо понятней и наглядней. После данной статьи я снова перечитал главу из книги, и пришел к тому же выводу что и для главы про model: не знакомому понятно сложно, а знакомый не найдет много нового и полезного.У Кайта было про сравнение с аналитикой? Или про ограничения? Или про фишку с permute? Или про {--} и "with unmatched rows"? Etc. А хоть краткий обзор производительности? (в эту тему будет некоторое углубление во второй части) moishamiemВ общем, хочется больше поясняющего текста, более плавный переход от простого к сложному.Учитывая аргументацию и выводы, я полагаю, что ты до сих пор не очень понял ни model ни pattern matching. В том смысле для чего инструмент, что с помощью него можно решить, а что нет и базовые best practices. Формулировки "мне кажется" или "ничего не понял" это на уровне домохозяйки, которая звонит в тех поддержку. У других отозвавшихся именно по этим двум разделам были диаметрально противоположные отзывы, но я подумаю как сделать текст более понятным. Текущий объем 114 страниц, и полагаю, чтоб реализовать "более плавный переход от простого к сложному" надо страниц 250. Это не выход. Чтение подразумевает пользование гуглом при необходимости. Ну и я отдаю себе отчет, что в повествовании делается достаточно быстрое погружение в тонкости, так что у меня нет иллюзий что книга будет интересна не разработчикам БД. Даже толковый джавист или сишарпник быстро отложит в сторону с вердиктом "ничего нипанятна". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 13:51 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
moishamiem, Ну и спасибо за отзыв. Без обид. Я понимаю, что всем всё равно не угодишь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 13:53 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
piheldbms_photoshop, 83 страница: Например, имеет информация по продажам за 12 месяцев и надо для каждого месяца отношение объема продаж к значению для первого месяца. ... select id, value, value / min(value) over() ratio from t может first_value(value) over() ?Да, спасибо, надо поправить. либо Код: plaintext Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 14:01 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, Да, конечно, без обид. Автору виднее как и для кого писать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 14:35 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
фотошоп нагенерировал фибоначчи через connect by, а столько воплей раньше было, что это невозможно)) про модель просто шикарно) когда вторая часть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2017, 22:02 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, Стр. 7До версии 9i в Oracle не было поддержки ANSI соединений, поэтому для соединения таблиц, их имена необходимо было перечислить во from и указать условия соединения в where. Oracle-specific syntax для соединений был впервые реализован в версии Oracle 6 . В ORACLE v5 и v4 был такой синтаксис. Предполагаю, что он же был и раньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2017, 21:24 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
оси лил целикомкогда вторая часть?По не зависящим от меня обстоятельствам несколько изменились приоритеты. Но работа потихоньку идет. Осталась одна глава и итоговая версия ожидается до конца апреля. SQL*Plusdbms_photoshop, Стр. 7До версии 9i в Oracle не было поддержки ANSI соединений, поэтому для соединения таблиц, их имена необходимо было перечислить во from и указать условия соединения в where. Oracle-specific syntax для соединений был впервые реализован в версии Oracle 6 . В ORACLE v5 и v4 был такой синтаксис. Предполагаю, что он же был и раньше.Я подразумевал внешние соединения, но из процитированного абзаца это совершенно непонятно. Надо переформулировать. Спасибо. https://blogs.oracle.com/optimizer/entry/outerjoins_in_oracle ince release 6, Oracle has supported a restricted form of left outerjoin, which uses Oracle-specific syntax. In 9i, Oracle introduced support for ANSI SQL 92/99 syntax for inner joins and various types of outerjoin. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2017, 23:20 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, Спасибо за книгу!=) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.03.2017, 08:40 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopоси лил целикомкогда вторая часть?По не зависящим от меня обстоятельствам несколько изменились приоритеты. Но работа потихоньку идет. Осталась одна глава и итоговая версия ожидается до конца апреля. SQL*Plusdbms_photoshop, пропущено... В ORACLE v5 и v4 был такой синтаксис. Предполагаю, что он же был и раньше.Я подразумевал внешние соединения, но из процитированного абзаца это совершенно непонятно. Надо переформулировать. Спасибо. https://blogs.oracle.com/optimizer/entry/outerjoins_in_oracle ince release 6, Oracle has supported a restricted form of left outerjoin, which uses Oracle-specific syntax. In 9i, Oracle introduced support for ANSI SQL 92/99 syntax for inner joins and various types of outerjoin.Посмотрю сохранившуюся документацию по ORACLE v5 в переводе РДТеХ.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.03.2017, 23:42 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, Спасибо за статью!!! осилил не знал о dbms_sql2.expand_sql_text не понял фразы стр 41 Если <order by> указано, то окно определяется от первой строки секции и до текущей если не указано другое стр54 Подобная сортировка не гарантирует сортировку корневых узлов, поскольку нельзя сказать, что они имеют общего родителя. имхо, ето был баг Код: plsql 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. стр 56 То есть если в условие соединения добавить level <= 1 и level <= 0, то в любом случае будут возвращены все строки первого уровня. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. стр 57 Ключевой момент при использовании connect by - это то, что невозможно генерировать дочерние значения на основании родительских. возможно имелось ввиду ВЫЧИСЛЕННЫХ родительских стр Для того, что выводились сначала дочерние элементы текущего узла, а потом остальные элементы на том же уровне необходимо использовать конструкцию search depth first - иными словами выполняется обход в глубину. По умолчанию результат выводится по уровням (search breadth first) - обход в ширину. Подобное поведение нельзя контролировать для connect by, при котором обход всегда выполняется в глубину. невозможно что сделать? стр 75 Всегда имеет смысл указывать сортировку в левой части правил содержащих диапазоны ячеек, поскольку - в таком случае улучшается производительность почему улучшается? стр 93 какую задачу решает пример (хотел проверить на 94стр ) еще раз СПАСИБО за труд ps если не трудно прономеровать примеры (сквозная или по разделам номерация) ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2017, 17:11 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
stax.. стр 56 То есть если в условие соединения добавить level <= 1 и level <= 0, то в любом случае будут возвращены все строки первого уровня. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2017, 17:54 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
условие совокупленияstax.. стр 56 То есть если в условие соединения добавить level <= 1 и level <= 0, то в любом случае будут возвращены все строки первого уровня. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. не понял, какого (чего) соеденения? Код: plsql 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. пример когда то в любом случае будут возвращены все строки первого уровня ...... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2017, 18:41 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
stax..не понял фразы стр 41 Если <order by> указано, то окно определяется от первой строки секции и до текущей если не указано другоеИмелось в виду, что Код: plaintext Код: plaintext Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Код: plsql 1. 2. 3. 4. 5. 6. 7. stax..стр54 Подобная сортировка не гарантирует сортировку корневых узлов, поскольку нельзя сказать, что они имеют общего родителя. имхо, ето был багПокажи где в доке/металинке указано, что гарантирует или что то был баг. stax.. стр 56 То есть если в условие соединения добавить level <= 1 и level <= 0, то в любом случае будут возвращены все строки первого уровня. Запрос не возвращает строк не из-за условия соединения, а из-за того, что условие старта не возвращает ни одной строки. Иными словами: если условие старта возвращает некоторые строки, а условие соединения заведомо ложное, то результат не будет пустым. stax..стр 57 Ключевой момент при использовании connect by - это то, что невозможно генерировать дочерние значения на основании родительских. возможно имелось ввиду ВЫЧИСЛЕННЫХ родительскихДа, так точнее. У меня эта формулировка встречалась несколько раз, вероятно в одном из случаев сформулировано недостаточно точно. stax..стр Для того, что выводились сначала дочерние элементы текущего узла, а потом остальные элементы на том же уровне необходимо использовать конструкцию search depth first - иными словами выполняется обход в глубину. По умолчанию результат выводится по уровням (search breadth first) - обход в ширину. Подобное поведение нельзя контролировать для connect by, при котором обход всегда выполняется в глубину. невозможно что сделать?Невозможно обойти дерево в ширину с помощью connect by. Можно rec with или моделью для любителей экзотики. stax..стр 75 Всегда имеет смысл указывать сортировку в левой части правил содержащих диапазоны ячеек, поскольку - в таком случае улучшается производительность почему улучшается?stax.. какую задачу решает пример (хотел проверить на 94стр ) На эти два момента позже отвечу. Пора бежать. Спасибо за отзыв. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2017, 20:11 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, авторПокажи где в доке/металинке указано, что гарантирует или что то был баг. наоборот, где сказано что левел 1 не сортируется имхо был баг, Елик предлагал искуственно вводить корень авторЗапрос не возвращает строк не из-за условия соединения, а из-за того, что условие старта не возвращает ни одной строки. Иными словами: если условие старта возвращает некоторые строки, а условие соединения заведомо ложное, то результат не будет пустым. не понимаю я русский стартовый возвращает Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. стартовый вернул три строки добавляю (раскоментирую) level<=0 Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. где то результат не будет пустым ? Код: plsql 1. 2. понятно что разные алгоритмы (и разные для разных версий оракля), но не проблема ж с имитацией вширь connect by Код: plsql 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. Кстати надо проверить обходит ли with вглубь, терзают меня смутные сомнения ps как копировать отмеченное в хххх? ...... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2017, 20:43 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
stax.. Кстати надо проверить обходит ли with вглубь, терзают меня смутные сомнения ...... stax создаем ф-цію, будет запомінать последовательнось вызовов в формате <id/level.rownum) Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. выполняем рекурсивный with в ширину Код: plsql 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. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. надеюсь траса понятна сначала первый уровень (2,3,11), потом второй (4,13,12, причем, 13 перед 12, нет сортировки), ..., последним третий уровень 5 все согласно построения вширь добавляю search depth first by id set ord Код: plsql 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. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. и что мы видим траса не изменилась, банально оракля вывел аля connect by siblings если бы обход шел вглубь то напр для 4 было бы <2/1.1> <3/1.2> <4/2.1> и тд пример в глубь Код: plsql 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. как и ожидалось первый уровень 2, нет детей переходим к 3-ке дальше детят 3, детя 4,... у 5 нет детей, опускаемся на уровень ниже до уровня 1, след 11, его дети,..., опускаеся уровнями ниже строк нет, выход ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2017, 22:10 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopstax..не понял фразы стр 41 Если <order by> указано, то окно определяется от первой строки секции и до текущей если не указано другоеИмелось в виду, что Код: plaintext Код: plaintext Это не совсем так, default windowing clause - Код: plaintext Regards Maxim ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2017, 23:47 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
Maxim Demenko, очепятался rows - range ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2017, 01:43 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
Maxim Demenko default windowing clause - Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2017, 11:54 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
stax..стартовый вернул три строки добавляю (раскоментирую) level<=0Давай вернемся к тому, что написал я Еще одним важным моментом является то, что проверка условия connect by выполняется после возврата строк на текущем уровне. То есть если в условие соединения добавить level <= 1 и level <= 0, то в любом случае будут возвращены все строки первого уровня. Строки первого уровня должны удовлетворять условиям start with и where если таковые имеются. условие соединения - предикат в connect by условие фильтрации - предикат в where Выполни это Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. stax..и что мы видим траса не измениласьПуть от корня к узлу и не должен был меняться. stax..Кстати надо проверить обходит ли with вглубьА вот здесь я ожидал, что при указании breadth first/depth first меняется алгоритм обхода, но по факту меняется только порядок выдачи, а обход всегда в ширину. Итак, есть дерево с двумя ветками. В первой узел с именем ABC ближе к концу, а во-второй ближе к корню. Задача найти ближайший узел с именем ABC. Код: plsql 1. 2. 3. 4. 5. 6. 7. Во втором случае я ожидал, что первая ветка будет обойдена до ABC, но ее обход остановился из-за того что ABC было встречено во второй ветке. нежданчик Код: plsql 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. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. То есть фраза https://docs.oracle.com/cd/E11882_01/server.112/e41084/queries003.htm subquery_factoring_clause, which supports recursive subquery factoring (recursive WITH) and lets you query hierarchical data. This feature is more powerful than CONNECT BY in that it provides depth-first search and breadth-first search Не очень правдива. Алгоритм обхода всегда в ширину. Меняется только порядок выдачи результата. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2017, 19:30 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
row_number()Maxim Demenko default windowing clause - Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2017, 19:38 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
stax..стр 75 Всегда имеет смысл указывать сортировку в левой части правил содержащих диапазоны ячеек, поскольку - в таком случае улучшается производительность почему улучшается?Потому что Ораклу не надо применять никакие механизмы для определения зависимостей между правилами. Зависимости могут быть как между строками так и между столбцами. По умолчанию Ораклу не надо анализировать зависимости между столбцами, т.к. применяется sequential order. Если применяется automatic order, то Оракл анализирует зависимости между столбцами (при наличии правил, где одна мера вычисляется на основании другой) Чтоб зависимости в рамках строк тоже были очевидны - имеет смысл указывать order by. При отсутствии order by Ораклу надо анализировать зависимости между строками (при наличии правил, где текущее значение меры вычисляется на основании значений для других строк) Как пример - рекурсия, зависящая от предыдущей строки Код: plsql 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. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. stax..стр 93 какую задачу решает пример (хотел проверить на 94стр ) Нумерует птичек (\/) у которых одно из крыльев может отсутствовать. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2017, 20:20 |
|
||
|
The Power of Oracle SQL
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopstax..стартовый вернул три строки добавляю (раскоментирую) level<=0Давай вернемся к тому, что написал я Еще одним важным моментом является то, что проверка условия connect by выполняется после возврата строк на текущем уровне. То есть если в условие соединения добавить level <= 1 и level <= 0, то в любом случае будут возвращены все строки первого уровня. Строки первого уровня должны удовлетворять условиям start with и where если таковые имеются. условие соединения - предикат в connect by условие фильтрации - предикат в where Выполни это Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. понял, правильное поведение отработал start with дальше по условию нет родителей, остаются только корни я под "условие соединения" понимал условия join тоесть у меня в иерархическом как минимум 4 типа условий в моей трактовке 1) уловие соединения e.empno=rr.r(+) 2) условие определения корня r is not null 3) условие построения иерархии (поиска детей) e.mgr = prior e.empno 4) условия фильтрации (and level<=1 and level<=0 закоментированы) dbms_photoshopstax..стр 75 Всегда имеет смысл указывать сортировку в левой части правил содержащих диапазоны ячеек, поскольку - в таком случае улучшается производительность почему улучшается?Потому что Ораклу не надо применять никакие механизмы для определения зависимостей между правилами. Зависимости могут быть как между строками так и между столбцами. По умолчанию Ораклу не надо анализировать зависимости между столбцами, т.к. применяется sequential order. Если применяется automatic order, то Оракл анализирует зависимости между столбцами (при наличии правил, где одна мера вычисляется на основании другой) Чтоб зависимости в рамках строк тоже были очевидны - имеет смысл указывать order by. При отсутствии order by Ораклу надо анализировать зависимости между строками (при наличии правил, где текущее значение меры вычисляется на основании значений для других строк) Как пример - рекурсия, зависящая от предыдущей строки Код: plsql 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. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. сортировка не обязательно уникальная, и всеравно надо что-то там анализировать мож просто меньше вариантов вопрос для меня спорный, но почему-то работает пример спицифический, сортировка по id и правило с ид cv(id)-1 поверю на слово (кстати, в статье в примерах сортировка не всегда прописана) dbms_photoshop То есть фраза https://docs.oracle.com/cd/E11882_01/server.112/e41084/queries003.htm subquery_factoring_clause, which supports recursive subquery factoring (recursive WITH) and lets you query hierarchical data. This feature is more powerful than CONNECT BY in that it provides depth-first search and breadth-first search Не очень правдива. Алгоритм обхода всегда в ширину. Меняется только порядок выдачи результата. и не менняется присвоение rownum, в отличие от connect by dbms_photoshop Я вроде про вертикальные/горизонтальные зависимости довольно много говорил когда писал про цикличность моделей. stax..стр 93 какую задачу решает пример (хотел проверить на 94стр ) Нумерует птичек (\/) у которых одно из крыльев может отсутствовать. :) на 94стр, пример о банкомате что делают правила понятно, не понятно какую жизненную задачу решает не надо обяснять, никому кроме меня не интересно СПАСИБ!!! ...... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2017, 16:33 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39431212&tid=1884482]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
51ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
67ms |
get tp. blocked users: |
2ms |
| others: | 223ms |
| total: | 386ms |

| 0 / 0 |
