Я не мучаюсь с PL+, я им наслаждаюсь!
|
| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
garsia
Участник со стажем
Вступление в Клуб: 01.11.2012
|
 Пт Ноя 23, 2012 08:38 Я не мучаюсь с PL+, я им наслаждаюсь! |
 |
Полезность: Нет оценки
|
Очень сложно от "нормального PL/SQL" перейти к PL+
Помогите разобраться с синтаксисом, пожалуйста!
Смотрел по базе, пробовал варианты запросов - ругается, синтаксическая ошибка.
Как создать PL/PLUS - представление из твух таблиц-справочников?
Типа :
type main is
select ( x(
x.[COL1],
x.[COL2],
y.[COL3]
)
in ::[DATA] x , ::[SPR] y
connect by prior y%id = x.REF_SPR
);
Представление создается внутри справочника DATA, реквизит которого REF_SPR является ссылкой на справочник SPR
Спасибо! |
|
 |
Volod
Эксперт
Вступление в Клуб: 19.09.2007
|
| Пт Ноя 23, 2012 08:48 |
|
Полезность: Нет оценки
|
М.б. так?
| Код: | | in ::[DATA] x , (::[SPR] :y) |
|
|
|
Nick
Участник со стажем
Вступление в Клуб: 07.11.2012
|
| Пт Ноя 23, 2012 08:54 |
|
Полезность: Нет оценки
|
попробуйте так
type main is
select x(
x.[COL1],
x.[COL2],
y.[COL3]
)
in (::[DATA] : x) , (::[SPR] : y)
connect by prior y%id = x.REF_SPR;
первая скобка не нужна, дальше неправильно заданы алиасы |
|
|
lexus
Профи
Вступление в Клуб: 28.09.2007
|
| Пт Ноя 23, 2012 10:14 |
|
Полезность: 1
|
| Volod пишет: | М.б. так?
| Код: | | in ::[DATA] x , (::[SPR] :y) |
|
уточнение
| Код: | | in ::[DATA] , (::[SPR] y) |
|
|
|
Nick
Участник со стажем
Вступление в Клуб: 07.11.2012
|
| Пт Ноя 23, 2012 10:38 |
|
Полезность: Нет оценки
|
| lexus пишет: | | Volod пишет: | М.б. так?
| Код: | | in ::[DATA] x , (::[SPR] :y) |
|
уточнение
| Код: | | in ::[DATA] , (::[SPR] y) |
|
самое изящное решение, первый вариант не будет работать из за отсутствия скобок |
|
|
garsia
Участник со стажем
Вступление в Клуб: 01.11.2012
|
| Пт Ноя 23, 2012 10:45 |
|
Полезность: Нет оценки
|
| Nick пишет: |
уточнение
| Код: | | in ::[DATA] , (::[SPR] y) |
|
Спасибо! Это заработало ) |
|
|
Nick
Участник со стажем
Вступление в Клуб: 07.11.2012
|
| Пт Ноя 23, 2012 11:17 |
|
Полезность: Нет оценки
|
| lexus пишет: | | Volod пишет: | М.б. так?
| Код: | | in ::[DATA] x , (::[SPR] :y) |
|
уточнение
| Код: | | in ::[DATA] , (::[SPR] y) |
|
кстати а в чем разница между объявлением алиаса с : и без?? Просто в документации написано с двоеточием |
|
|
svn
Профи
Вступление в Клуб: 04.02.2008
|
| Пт Ноя 23, 2012 12:18 |
|
Полезность: Нет оценки
|
в старых версиях ТЯ двоеточие обязательно было - на современных упростили синтаксис, но привычку не перебьёшь)
рекомендую ставить модификатор all в типах - а то бывают нюансы и не суразности |
|
|
Nick
Участник со стажем
Вступление в Клуб: 07.11.2012
|
| Пт Ноя 23, 2012 12:21 |
|
Полезность: Нет оценки
|
| svn пишет: | в старых версиях ТЯ двоеточие обязательно было - на современных упростили синтаксис, но привычку не перебьёшь)
рекомендую ставить модификатор all в типах - а то бывают нюансы и не суразности |
понятно, для оптимизации запросов all можно убрать если нет необходимости просматривать все поля, я так понимаю? |
|
|
lexus
Профи
Вступление в Клуб: 28.09.2007
|
| Пт Ноя 23, 2012 12:27 |
|
Полезность: Нет оценки
|
| svn пишет: | в старых версиях ТЯ двоеточие обязательно было - на современных упростили синтаксис, но привычку не перебьёшь)
рекомендую ставить модификатор all в типах - а то бывают нюансы и не суразности |
это от задачи зависит.
Но, знать и помнить о модификаторах all и collections надо. Тут вы правильно внимание обратили, поддерживаю. |
|
|
Random
Эксперт
Вступление в Клуб: 27.06.2011
|
| Вт Дек 04, 2012 08:31 |
|
Полезность: 2
|
| Nick пишет: | | svn пишет: | в старых версиях ТЯ двоеточие обязательно было - на современных упростили синтаксис, но привычку не перебьёшь)
рекомендую ставить модификатор all в типах - а то бывают нюансы и не суразности |
понятно, для оптимизации запросов all можно убрать если нет необходимости просматривать все поля, я так понимаю? |
модификаторы all, collection относятся к массивам. Например, FACT_OPER.
Массивы, это если в таблице есть поле collection_id (есть тип Массив элементов данной таблицы, например, FACT_OPER_ARR, а главное - есть владелец, то есть тип, у которого есть реквизит типа "массив", например, PR_CRED.LIST_PAY).
Без модификатора, при обращении к такому типу, в pl/sql-коде автоматически добавляется условие:
select a(a%rowtype) in ::[FACT_OPER] транслируется в select * from z#fact_oper where COLLECTION_ID IS NULL !!!
то есть при использовании типа без модификатора подразумевается, что вы пользуетесь им как справочником.
С модификатором collection - обратная ситуация:
select a(a%rowtype) in ::[FACT_OPER] collection транслируется в select * from z#fact_oper where collection_id is NOT null !!!
то есть подразумевается, что вам необходимы элементы коллекций, а свободные справочные данные не интересны.
Модификатор all необходим, если вам не нужны умствования транслятора и всякие неявные условия.
select a(a%rowtype) in ::[FACT_OPER] all транслируется в select * from z#fact_oper !!!
Нужны все данные - получите все данные.
А ноги растут в лени (или гениальности) программистов ЦФТ - в одном и том же типе могут храниться как справочные данные, имеющие самостоятельный смысл, так и элементы массивов с владельцами, которые смысла без владельцев (тех же кредитов) не имеют. Соответственно, такое объединение устраняет необходимость в новых справочниках (или в новых массивах) (они потом всё равно добавляются, но уже с бОльшими трудозатратами по переносу данных). То есть согласно принципу бритвы Оккама - не плодить сущностей сверх необходимого.
PS: это всего лишь моё мнение. |
|
|
Эмиралька
Эксперт
Вступление в Клуб: 09.11.2015
|
| Пт Мар 17, 2023 10:13 |
|
Полезность: Нет оценки
|
дополню, что collection_id - это фиктивное поле, нет никаких констрейнтов, которые показали бы связь между владельцем массива и самим массивом.
По сути же у владельца массива (например, PR_CRED) есть поле-число, содержащее число, например, 456456, и то же число записывается в collection_id таблички-массива (например, FACT_OPER).
Соответственно, все записи из таблички FACT_OPER, отмеченные 456456 являются элементами массива LIST_PAY кредита, у которого поле LIST_PAY = 456456.
Один кредит = много записей массива.
Чем удобно?
Тем, что в точности такие же фактические операции могут быть в другой табличке, в депозитах, в портфелях однородных ссуд и так далее. Алгоритмы обработки данных работают с одной и той же табличкой FACT_OPER, и не дублируются. |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
|
О проекте
Поиск
Отзывы
Регистрация
Вход
