подскажите. пожалуйста,

вот кусочек моего селекта
select g.c_main_v_id -- , g.id , g.id_1, g.lnk_acc, g.h
,
(select count(b1.ID)
from ibs.Z#RKO_CUR b1
where b1.C_ACC_TRANS = g.id) A$2
from (select acc_num.c_main_v_id,
acc_num.id,
acc_num.c_accs_arr,
acc.id id_1,
lnk.c_account lnk_acc,
null h
from Z#LINK_ACCS lnk, z#AC_FIN acc, z#AC_FIN acc_num
where acc.c_ACCS_ARR = lnk.COLLECTION_ID
and lnk.C_VID in (1920715, 9012478)
and lnk.c_account = acc_num.id
--and acc.id in (46666995947)
union
select nvl(acc_num.c_main_v_id, lnk.c_acc_num) c_main_v_id,
acc_num.id,
acc_num.c_accs_arr,
acc.id id_1,
acc_num.id lnk_acc,
null h
from Z#LINK_ACCS lnk, z#AC_FIN acc, z#AC_FIN acc_num
where acc.c_ACCS_ARR = lnk.COLLECTION_ID
and lnk.C_VID in (1920715, 9012478)
and lnk.c_acc_num = acc_num.c_main_v_id(+)
and acc.c_client_v = acc_num.c_client_v(+)
--and acc.id in (46666995947)
) g
connect by prior g.lnk_acc = g.id_1
start with g.id_1 = v_AccId(i) -- 46666995947

не могу придумать, как сделать, чтобы , если отобрался lnk.c_acc_num - отмечен красным. то есть вот это условие не отработает- connect by prior g.lnk_acc = g.id_1, как мне тогда продолжить бы выполнение цикла ? то есть в коннект бай задать два альтернативныху словия- чтобы в зависимости от того, пустой или заполненный acc_num.c_main_v_id,- соединение шло по разным веткам.

это можно сделать?

заранее благодарна.
сильно. поверьте.

ElicОзорнитказаранее благодарна.
сильно. поверьте.Настолько, что соизволил пренебречь тэгом SRC?!

соизволилА

ЗаггиВидали мы эту "благодарность" 20858465

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

MaximaXXLОзорнитка,

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

Пока могу сказать:
Озорниткаесли отобрался lnk.c_acc_num - отмечен красным. то есть вот это условие не отработает- connect by prior g.lnk_acc = g.id_1
верю на слово, хтоя подразумеваю что отработает но не так как Вам бы хотелось

Озорниткато есть в коннект бай задать два альтернативныху словия- чтобы в зависимости от того, пустой или заполненный acc_num.c_main_v_id,- соединение шло по разным веткам.
А, извините, какие? Первое prior g.lnk_acc = g.id_1 - вижу (к c_main_v_id отношения не имеет), а второй?

все отработает . как надо- поскольку я уже все оттестировала

g.lnk_acc = g.id_1 - имеет отношение к c_main_v_id,

1) спускаемся вниз от acc.id: lnk- по collection_id связано с acc (ACCS_ARR =collection_id и все lnk.id , у которых такой колекшен - относятся к acc ), затем у LNK берем ACCOUNT и теперь принимаем его за acc

2) так же спускаемся вниз от acc: тот же lnk, тот же коллекшион, но теперь счет может быть записан не в виде ссылки ACCOUNT, а просто - норме строкой acc_num. Теперь нам надо в фин счетах найти нужный счет и опять принять его за acc/
Проблема в том, что данные могут быть ошибочны и может быть указан номер счета, который в базе не существует, и в таком случае мне хотелось бы в коннект бай указать другое условие

аналогичный селект (просто с другими условиями) есть для поиска 'вверх', но его смысла нет приводить.

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

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

но просто стало интересно, а если бы были- то можно ли это сделать одним запросом

короче, надо было тему под другим ником создать :)

а то злопамятные )

да это колонка для селекта поиска вверх, там оно заполняется, а себе сделала одинаковый набор в обоих запросах, чтобы не запутаться

блен, я with не пользуюсь никогда :(

ну ладно, сделаю, выложу

loperfооо, таблицы из ЦФТ ;)

когда я уже уйду от Цфт :(

хочу проста на пл скул.. и еще лучше в придачу с жабой. Ваще была бы счастлива

у меня дома нет компа щас,

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

cast(null as number)- это зачем

andrey_anonymousОзорниткаcast(null as number)- это зачем
Тип поля задает.

так и без этого работает

оракл неявно преобразует?

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

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


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

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

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

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

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

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