Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
Наглядный пример такого запроса (WITH ...) показан Paul Atreidies в /topic/29091 (16 апр 03, 14:02). Приведенная DimaR конструкция в Oracle с CONNECT BY (там же, 17 апр 03 13:09), на мой взгляд, ориентирована строго на древовидные иерархии. Это только подмножество из возможной области применения рекурсии в запросе. Исходя из этого, я бы проставил такие значения:\r Рекурсивные запросы.\r IBM DB2 (v.8?) +\r Oracle 9i (release 2?) +/-\r MS SQL Server 2000 -\r Поправьте, пожалуйста, если я ошибаюсь.\r \r И вопрос к тем, кто использует SQL Server. Насколько необходимо, на ваш взгляд, вводить такую возможность, в след.версии (Yukon)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 12:18 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
В оракле в любом релизе, начиная с 7.0. Ограничение - работа только с одной таблицей в запросе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 12:25 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
К вопросу нужно ли это в Yukon Мое мнение - крайней необходимости нет, но было бы неплохо. Я пользуюсь структурой данных на основе статьи sqltrees на этом сайте. ID,Parent,LeftBound,RightBound. Есть некоторая избыточность. Но для того чтобы выбрать к примеру все дочерние записи. То всего лишь (условно) SELECT * FROM Tree WHERE LeftBound > @LeftBound and RightBound < @RightBound При наличии соответствующих индексов думаю этот запрос выполнится быстрее любого рекурсивного, хотя могу и ошибаться. Вообщем пользы от рекурсивного запроса большой не будет. Но при использовании стандартной схемы ID,Parent рекурсивные запросы могут оказаться очень полезными и избавят разработчика от написания процедур обработки деревьев ( они как правило основы на поуровневой выборке) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 12:45 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
2Al: Ну почему же, а select .. from (select ...)? Те. в подзапросе подготавливаешь данные, потом в верхнем ставишь CONNECT BY. 2Дед Маздай: а можно сформулировать определение рекурсивного запроса? Paul Atreidies говорил о нем как о "возможности запроса ссылаться на самого себя". Если в DB2 под этим понимается использование оператора WITH, то в Oracle 9.2 он присутствует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 12:48 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
Маленький добавчик. Получился частный случай. Я хотел этим показать, что вместо использования рекурсии, часто помогает перепроектирование структуры. Я затрудняюсь привести пример, когда использование рекурсии является наиболее оптимальным решением. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 12:54 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
Ну да, возможность запроса ссылаться на себя. Если это решается с помощью WITH, то мне непонятно, зачем еще иметь CONNECT BY. По поводу нескольких таблиц в рекурсивном запросе написано: "... a multi-table query cannot contain the CONNECT BY clause. So, unlike the procedure, the SQL statement cannot be modified to do joins". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 13:05 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
Принцип работы в дб2 Есть некоторый исходный набор данных (таблица, вьюшка, табличное выражение). Из него выбирается стартовый набор строк. Он соединяется с исходным набором. Полученный результат опять соединяется с исходный набором данных. И так до тех пор пока результат соединения будет не пустым. Область применения - какое-то подмножество алгоритмов на графах вроде поиска в ширину. Возможно зацикливание - само собой :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 13:11 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
Вместо рекурсивного запроса куда ценнее было бы в Yukon'e реализовать: 1) Снять ограничение на глубину рекурсий процедур. Т.е. ограничить только размером стэка. 2) Снять ограничение на вложенное "insert exec" или реализовать select * from (exec proc) без ограничения вложенности. 3) Разрешить использования переменных в OPENQUERY и т.п. вместо констант. Перечисленное перекрывает рекурсивные запросы и по удобству и по функциональности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 13:18 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
Согласен с Dankov И вообще побольше ортогональности - ну почему я не могу использоватать оператор OR между select и from, а после where - могу ! Да и вообще надо-бы сделать TSQL более похожим на современные языки - с удобными структурными операторами, обработкой исключений А рекурсия сама пойдет :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 14:51 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
Дело вкуса... :) Работа с БД - это операции над множествами и мыслить нужно категориями множеств. Лично мне не нравятся процедурные расширения, построчная обработка и т.д. Это имхо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 15:05 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
to Paul Atreidies: тогда тебе подойдет APL :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 15:12 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
построчная обработка - это понятно. а что не нравится в процедурной обработке множества записей - это непонятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 15:54 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
2Dankov Вместо (или вместе) всего этого сделали-бы там возможность передачи в процедуру переменной-таблицы (естественно, в виде ссылки) и ещё пользовательский табличный тип (для обеспечения раннего связывания) Это сразу подняло-бы MSSQL на такую высоту... Ну сколько мы-бы не рассуждали здесь... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 17:41 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
Вопрос был задан так: Paul Atreidies > Поддерживает ли сервер рекурсию (хоть какую) в операторе SELECT?. Поэтому для оракла нужно отвечать Да (+), без всяких (+/-) Вопроc: Можно ли в MSSQL рекурсивный запрос реализовать с помощью UDF, возвращающих рекорд сет? Более конкретно: позволяют ли такие UDF рекурсивные вызовы? 2 Crip >Я хотел этим показать, что вместо использования рекурсии, часто помогает перепроектирование структуры. Перепроектирование структуры всегда помогает. Вопрос только в том, сколько вокруг этого траха ((С) чингиз). >Я затрудняюсь привести пример, когда использование рекурсии является наиболее оптимальным решением. Например то же дерево, которое является очень распространенной структурой. Задача: для данных двух вершин выяснить, связаны ли они отношением предок-потомок. Можно написать триггеры и добавлять (удалять) всех потомков в отдельную таблицу вида (z, z_потомки). При этом нужно не забыть все пересчитать при перерносе поддерева на другую вершину. Сильно замедлится время для инсертов, делитов и апдейтов и усилится головная боль от написания триггеров. Еще решение: можно вместо select все считать в SP или UDF, но тут мелькала информация об ограниченной глубине рекурсии (кстати сколько в случае MSSQL2000?). По-моему рекурсивный seleсt в данном случае отимальнее. Но я не берусь доказывать, что он наиболее оптимальный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2003, 07:13 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
2c127 Задача: для данных двух вершин выяснить, связаны ли они отношением предок-потомок В приведенной мною структуре эта задаче решается проверкой невходит ли диапозон одного в другой(одна операция сравнения) . Я так понимаю с этой статьей вы не знакомы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2003, 10:30 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
Я читал когда-то. Насколько помню - это решение в определенных случаях, но: 1. работает только для дерева - когда корневых вершин несколько начинаются проблемы. 2. Достаточно недетская процедура вставки новых данных. 3. В запросах выборка выглядит достаточно тяжелой - join на принадлежность множеству. Т.е. производительность :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2003, 12:40 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
1. работает только для дерева - когда корневых вершин несколько начинаются проблемы. Хм... Не внимательно значит читали... 2. Достаточно недетская процедура вставки новых данных. Это вы загнули... Впрочем может быть для кого-то единственный Update границ может оказаться очень критичным. 3. В запросах выборка выглядит достаточно тяжелой - join на принадлежность множеству. Т.е. производительность Вы так полагаете? При наличии соотвествующих индексов все проходит достаточно быстро и уж я думаю куда быстрее чем рекурсивные вызовы...Хотя это в значительной степени зависит от того как эти вызовы реализованы, к сожалению с DB2 малознаком... Тем не менее для нескольких тысяч записей у меня проблем никаких. Для небольшего не тестировал... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2003, 12:58 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
2 Crip 1. Честно говоря не увидел - или ткните пальцем - или просто кратко опишите на случай несвязного графа. 2. Вставка при "традиционном" методе не треьует изменения остальных записей. В случае вложенных множеств потредуется пересчет достаточно "большого" количества записей - я не говорю что это много по времени - это много в сравнении со вставкой одной записи :). Дальше я не уверен (при желании можно посчитать посчитать), но на первый взгляд в среднем что-то около n/2 строк при вставке случайных данных. n-число строк. Пример в статье со вставкой смежной, крайней правой не очень удачет - он достаточно прост. То же и при удалении. 3. Она и при работе с такой структурой неявно присутствует - это видно по запросам (для каждой вершины идет поиск в глубину): Код: plaintext 1. 2. 3. 4. 5. Согласитесь что этот join потяжелее чем на равенство :). Я ничего не имею против такого метода хранения. Просто иметь встроенные средства поддержки рекурсии, на мой взгляд, предпочтительнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2003, 14:27 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
1. Честно говоря не увидел - или ткните пальцем - или просто кратко опишите на случай несвязного графа. Честно говоря погорячился... Конечно это работает только для дерева. Решение для множества корней сделано у меня сделано через дополнительную таблицу. Согласитесь что этот join потяжелее чем на равенство :). Я ничего не имею против такого метода хранения. Просто иметь встроенные средства поддержки рекурсии, на мой взгляд, предпочтительнее Возможно вы правы. Своим примером я лишь пытался показать, что возможно приемлиемое решение проблемы без использования встроенных механизмов. Хотя по-поводу графов не так просто что-то придумать на таком высоком уровне как программирование БД. Вообще лично у меня возникает впечатление, что все-таки глубокой проработкой отдельных деталей, характерной для DB2 и Oracle, разработчики MS не занимаются, в основном сосредотачивая усилия на улучшении стандартных механизмов( оптимизатор etc.) . Это вероятно позволяет привлечь массового потребителя, но в узкоспециализированных задачах SQL server наверняка проигрывает DB2 и Oracle. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2003, 14:48 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
2 Crip Прочитал статью. Интересно, может когда пригодится. Недостатки такого решения тут уже обсуждались. К тем двум альтернативам (кстати в первй из них задача тоже решается одним запросом), которые я упоминал добавилась третья - Celko. У рекурсивного запроса по-прежнему остается по крайней мере одно преимущество: простота. Ничего вообще менять не надо. Это важно, если необходимость рекурсивных запросов вдруг появилась в середине проекта. Поэтому рекурсивные запросы иметь в своем арсенале было бы очень непохо. Я абслютно согласен, что приведенные тут альтернативные решения в некоторых случаях предпочнительнее (например select будет работать быстрее). Случай многих деревьев по-моему полностью закрывается решением Celko если добавить общий корень. В смысле теории это тривиально, но я говорю о реализации. Основные запросы вроде не меняются. Насколько я знаю термина "вложенные множества" в математике нет. Есть подмножества и есть множества, элементы которых в свою очередь есть множества. Автор статьи по-видимому имеет в виду последние. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2003, 01:30 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
Захотелось поднять тему. Скажите, можно ли в различных СУБД только средствами SQL реализовать получение чисел Фибоначчи?\r \r /topic/75150#542297 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2004, 11:36 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
Давайте лучше дифуры решать с помощью SQL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2004, 11:55 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
2 Дед Маздай Не то чтобы совсем нас спрашивали о том нужно это или нет в Yukon. Но это уже включено туда. Вот пример кода из журнала www.sqlmag.com за Ноябрь 2003 года. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2004, 15:13 |
|
||
|
Рекурсивные запросы
|
|||
|---|---|---|---|
|
#18+
Наконец-то Дед Маздай узнал! С апреля человек ждал... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2004, 17:17 |
|
||
|
|

start [/forum/topic.php?fid=35&fpage=51&tid=1554180]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
24ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 191ms |
| total: | 290ms |

| 0 / 0 |
