а кстати в моем запросике так-то ошибка была -таки,
на определенных данных зацикливался

но легко исправляемая


а вообще, наверное, лучше избегать использовать слишком массивные запросы? чтобы следующим разрабам было проще сопровождать написанный тобой код ?

или нет? слышала мнение, что , если можно сделать одним запросом- то нужно делать одн им запросом, а не плеядой циклов.
вы как считаете ?

простота сопровождения кода с несколькими циклами или написать компактно один, но большой запрос ? что предпочтительнее ?

envОзорнитка,

Предпочтительнее формировать архитектуру таким образом, чтобы не требовалось делать подобных запросов.

А при отсутствии возможности управлять архитектурой и составом данных - под каждую задачу будет своё оптимальное решение, где-то простынёй в виде запроса, где-то пучком циклов.

а каким образом вы сформируете структуру иерархических данных без иерархии? денормализовать что ли? это же не хранилища

andrey_anonymousОзорниткаа каким образом вы сформируете структуру иерархических данных без иерархии? денормализовать что ли? это же не хранилища
Неплохие результаты показывает такая структура, как классификатор .

можно ссылку ? в гугл по запросу :'oracle проектирование БД классификатор' выдается фигня

andrey_anonymous,

спасибо

envЗаггибез головной боли, как у топикстартера?
Головная боль ТС - архитектура, при которой в один запрос собирается "иерархия" через union с условным переходом по факту отсутствия данных в одной из таблиц. А не иерархическая структура как таковая.

ааа. вы имеете в виду ставить жесткие ограничение и констрейнты на саму возможность заполнения таблиц ?

andrey_anonymousОзорниткапропущено...

можно ссылку ? в гугл по запросу :'oracle проектирование БД классификатор' выдается фигня
https://ru.wikipedia.org/wiki/Классификатор

прочитала статью, честно говоря , не поняла, как она соотносится с моей задачей в том контексте, который вы вложили в сообщение (какая-то идеальная структура данных, которая исключит мои проблемы выше, не иерархия)

там три классификации: иерархия, фасеточная и дескрипторная. Из трех мне наиболее понятна иерархия и кажется наиболее удобной для решения моей задачи. То есть такая, какая сейчас и есть.

поможете понять вашу мысль ? что имели в виду ?

попа

в данных теперь ситуация, что счет забит не строкой- а один и тот же счет забит несколько раз одинаковыми записями. На коих мой большой коннект бай благополучно зацикливается

скажите пожалуйста, а параметр - NOCYCLE - это сильно плохо ?
попробовала использовать - после счета, на котором циклится- есть еще один шаг далее, и он выполняется. То еть отбирается вся цепочка необходимых счетов.


сначала пробовала сделать row_number и брать ограниченное число записей в один отбор (тк проверила запросом, что все задвоенные записи- это тупо дубли). Но ломался план настолько , что невозможно долго.


блин.
кто там говорил мне , что запрос будет работать не совсем так, как мне кажется ?
был прав .

Апосля вчерашнегоТам есть раздел про кодирование.
Но смысл очень простой - код классификатора определяет положение элемента в структуре полностью.
К примеру:
1.00.00 - рут
1.01.00 - чилд1-1
1.01.05 - лист
Запросы к такой структуре не требуют connect by - достаточно like

спасибо! стало понятно!

вобщем,
поспрашивала у коллег - nocycle мне подходит по причине того, что задвоенные записи- дубли. То есть цикл идет по первой отобранной ветке далее, и меня это устраивает. Тк вторая запись всегда дубль, то есть тот же самый счет, который и был отобран в первой ветке


фух.

ElicОзорнитказадвоенные записи- дубли99% - быдлозапрос в основе.

ну второй вариант - это куча циклов. Если данные такие корявые, какое бы вы предложили другое решение ?

по поводу нормализации данных - предлагала аналитику. Он отказал , основываясь на том, что задача слишком большая, поскольку нужно будет проанализировать и выявить весь функционал, который эти корявые данные плодит.

остается только на них закладываться значит.
что может быть:
1) запись одной информации в разных атрибутах (отсюда разный алгоритм поиска счета для продолжения цикла) :
- в одном случае ссылкой на счет
- в другом случае просто строкой
2) дубли (в этом случае подойдет отобрать один первый счет, остальные записи пропустить, тк они дубли)

у вас есть лучший вариант?

envОзорнитка,




Какой вопрос, такой и ответ

кстати, интересное сообщение
не знала, что можно колонки для отбора в иерархическом запросе писать (prior id)*-1 и использовать case в условии connect by

StaxОзорниткавобщем,
поспрашивала у коллег - nocycle мне подходит по причине того, что задвоенные записи- дубли. То есть цикл идет по первой отобранной ветке далее, и меня это устраивает. Тк вторая запись всегда дубль, то есть тот же самый счет, который и был отобран в первой ветке
фух.

дубли действительно из-за данных, или возможно из-за "соеденения" таблиц?

.....
stax

первым делом проверила

в данных дубли