Нужен аналог "...TABLE_1 left outer join (TABLE_2, TABLE

← →
Курдль © (2005-12-12 16:48) [0]

Приветствую!
С привеликим удовольствием вернулся к Ораклу, но многое уже подзабыл.
Сейчас переделываю проект под Оракл. Есть конструкции, которые не поддаются изящной трансформации. Например, внешние соединения основной таблицы с групой подчиненных вида

"...from T1 left outer join (T2, T3) on T3.T2_ID = T2.T2_ID and T2.T1_ID = T1.T1_ID"

Как бы это адаптировать под оракл?

← →
evvcom © (2005-12-12 16:56) [1]

А что твой оракл такое не кушает? Ну ты бы хоть версию указал. А то телепатить приходится. Восьмерка чтоль?

← →
Курдль © (2005-12-12 17:08) [2]

Версия - девятка.
Ругается на скобки, если их убрать - ругается на отсутствие ключевого слова (спотыкается об запятую).

← →
Desdechado © (2005-12-12 17:16) [3]

а Language Reference почитать?

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

← →
ANB © (2005-12-12 17:31) [4]

> Курдль © (12.12.05 16:48)

Или поставь плюсики в связках (в where). И не парься.
ЗЫ. Тогда и на 8 работать будет.

← →
Vlad © (2005-12-12 17:31) [5]

Курдль © (12.12.05 17:08) [2]

в девятке left outer join поддерживается. Но не уверен что такую конструкцию скушает
left outer join (T2, T3)
скорее всего по одной таблице джоинить надо.
А вобще, в Оракле outer join делается прям в условии where

where
a.id = b.id(+) and c.id = d.id(+)

см. доки по (+)

← →
Курдль © (2005-12-12 17:35) [6]

> не знаю, как насчет группового соединения, но можно нормально
> и по одному раскидать

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

← →
ANB © (2005-12-12 17:42) [7]

> Курдль © (12.12.05 17:35) [6]

Вот говорил же я, что писать универсальные программы под любые СУБД - жуткий геморрой. :)

← →
Курдль © (2005-12-12 17:44) [8]

> А вобще, в Оракле outer join делается прям в условии where

У меня задача - запросы максимально приближать к ANSI.

В твоем примере

> where
> a.id = b.id(+) and c.id = d.id(+)

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

← →
ANB © (2005-12-12 17:49) [9]

> Курдль © (12.12.05 17:44) [8]

Запихать связку T2 и T3 во вложенный запрос во from

← →
Курдль © (2005-12-12 17:52) [10]

> ANB © (12.12.05 17:42) [7]
>
>
> > Курдль © (12.12.05 17:35) [6]
>
> Вот говорил же я, что писать универсальные программы под
> любые СУБД - жуткий геморрой. :)

Программа писалась под сайбэйс, но с оглядкой, что возможен переход на другую СУБД. И вот оно свершилось.
Кстати, не так уж страшен черт, как его малютка! Огромный проект из нескольких сотен файлов исходника без особого труда переведен с сайбэйса на оракл.
Осталось поменять в запросах DateFormat на ToChar, IsNull на NVL и т.п. по мелочам. На делфях бы так не удалось :)

← →
ANB © (2005-12-12 17:57) [11]

> На делфях бы так не удалось :)

А на чем писали ?

← →
Vlad © (2005-12-12 18:39) [12]

> Курдль © (12.12.05 17:44) [8]
>
> в набор данных попадут записи из таблицы b независимо от
> содержимого таблиц c и d.
> А если ты внимательно посмотрел мой исходный запрос - там
> сначала делается выборка из таблиц Т2, Т3 по определенному
> условию и только полученный результат внешне соединяется
> с Т1.

Я вобще не заморачивался с тем, что там куда попадет, а просто привел тебе пример конструкции с внешним join-ом.

> У меня задача - запросы максимально приближать к ANSI.

Практика показывает, что бесполезная трата времени и сил. При переходе на другую СУБД все равно многое править приходится.

← →
evvcom © (2005-12-13 09:01) [13]

> "...from T1 left outer join (T2, T3) on T3.T2_ID = T2.T2_ID
> and T2.T1_ID = T1.T1_ID"

Максимально похоже:
"...from T1 left outer join (T2 inner join T3 on T3.T2_ID = T2.T2_ID) on T2.T1_ID = T1.T1_ID"

← →
Курдль © (2005-12-13 09:55) [14]

> ANB © (12.12.05 17:57) [11]
> А на чем писали ?

На MS VS.

> > У меня задача - запросы максимально приближать к ANSI.
> Практика показывает, что бесполезная трата времени и сил.
> При переходе на другую СУБД все равно многое править приходится.

Моя практика показывает, что наоборот, это сильно облегчает работу.
Во-первых помогает глубже проникнуться идеологией SQL (это как писать сочинение на Русском, а не на "SMS-слэнге").
Во-вторых - позволяет оставлять неизменной структуру запроса, изменяя лишь некоторые ключевые слова.
Например, "IsNull" на "NVL", "If ... Else" на "Decode", "DateFormat" на "ToChar".
Конечно, в этом частном случае можно было бы и транзакт SQL привести к PL/SQL типа where T1.T2_ID = T2.T2_ID(+) where T1.T2_ID *= T2.T2_ID
А что делать, если возникнет необходимость перейти на еще какую-нибудь СУБД?

> evvcom © (13.12.05 09:01) [13]
> Максимально похоже:
> "...from T1 left outer join (T2 inner join T3 on T3.T2_ID
> = T2.T2_ID) on T2.T1_ID = T1.T1_ID"

Точно! Я тоже до этого же дошел и даже поделился такой мыслью на SQL.RU!

← →
evvcom © (2005-12-13 10:04) [15]

> "If ... Else" на "Decode",

Тогда уж на case. Case в стандарте имеется. А что сайбейс в селекте допускается конструкция "If ... Else" и нет Case?

← →
Курдль © (2005-12-13 10:23) [16]

> evvcom © (13.12.05 10:04) [15]
> Тогда уж на case. Case в стандарте имеется.

Согласен. Так удобнее.

А что сайбейс
> в селекте допускается конструкция "If ... Else" и нет Case?

Сайбэйс имеет в селекте и "If ... Else" и Case. Сайбэйс много чего имеет.
Люблю эту СУБД и считаю, что она оставила далеко позади MS SQL.
Но с ораклом она все равно не сравнится. :(

← →
evvcom © (2005-12-13 10:30) [17]

> Сайбэйс имеет в селекте и "If ... Else" и Case.

Ну так и надо было сразу Case и использовать, а if...else в селекте - это не стандарт. Дааааа... Каждый разработчик по-своему извращается (это я про разработчиков сайбейз). :)

> Люблю эту СУБД и считаю, что она оставила далеко позади MS SQL.
> Но с ораклом она все равно не сравнится. :(

А у нас некоторые считают, что MSSQL круче оракла, т.к. MSSQL сам решает некоторые задачи, а в оракле надо явно указать, как эту задачу решить! А для этого ж его надо понимать! Я уж с ними не спорю - бесполезно :)

← →
Курдль © (2005-12-13 10:38) [18]

> А у нас некоторые считают, что MSSQL круче оракла

Если мне лень спорить то бывает достаточно одного аргумента: "MS SQL - блокировщик" и на этом спор обычно заканчивается :)
(хотя это далеко не единственное преимущество оракла).

← →
evvcom © (2005-12-13 10:47) [19]

На этот аргумент приводят "свой": "А вот MS исправят это, и тогда по всем параметрам обскачут Оракла!" Потому и не спорю. С фанатами без мозгов спорить бесполезно.

← →
ANB © (2005-12-13 11:13) [20]

> "А вот MS исправят это, и тогда по всем параметрам обскачут
> Оракла!"

Еще и язык перепишут :)))

← →
Курдль © (2005-12-13 12:07) [21]

> evvcom © (13.12.05 10:47) [19]
> На этот аргумент приводят "свой": "А вот MS исправят это,
> и тогда по всем параметрам обскачут Оракла!"

Я теоретически допускаю такой вариант. Согласитесь, что у MS появилось немало приличных продуктов. И даже винды уже совсем не те, что были раньше.
VS.NET довольно сильная весчь. Конечно подглючивает, подтормаживает :), но работу титаническую выполняет. Для средства разработки это допустимо. А вот если СУБД будет подглючивать и подтормаживать...
И, честно говоря, я не понимаю, что им стоило в своем MS SQL сделать по людски, - ведь давно понятно, что должна включать в себя приличная СУБД - последовательности, триггеры "before"... и мн.др. чего нет в MS SQL.

← →
evvcom © (2005-12-13 12:37) [22]

> последовательности, триггеры "before"... и мн.др. чего нет
> в MS SQL.

Ну без последовательностей я легко обходился в MS SQL. Мне хватало IDENTITY. Оно и в оракле последовательности использую пока только для генерации первичного ключа, другой надобности пока не возникало. Триггеры, если мне не изменяет память, в MSSQL есть и before и after. Нет триггеров for each row, вот это правда. Всвязи с чем нет и проблемы "изменяемой таблицы" (mutating table). :)

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

← →
ANB © (2005-12-13 12:46) [23]

> Всвязи с чем нет и проблемы "изменяемой таблицы" (mutating
> table).

Во во. Грабля еще та. И вылезает, где ни попадя. Кстати, я и в обычных хранимках на это нарывался. Когда сложная цепочка вызовов и пакетный апдейт, то на раз на эту граблю наступить.

> evvcom © (13.12.05 12:37) [22]
> Ну без последовательностей я легко обходился в MS SQL. Мне
> хватало IDENTITY.

Кстати, меня сильно поразило то, что в MS SQL отсутствовало даже многое из того, что есть в его прототипе Sybase ASA от Watcom. Например, того же
GET_IDENTITY ( [ owner.] table-name [, num_to_alloc ],... )

> Например, того же GET_IDENTITY

Может и полезная вещичка, но я и без нее обходился. Сразу за инсертом, читаешь глобальную переменную @@IDENTITY (так вроде, опять же если память не сбоит)

> evvcom © (13.12.05 14:32) [26]
> Может и полезная вещичка, но я и без нее обходился. Сразу
> за инсертом, читаешь глобальную переменную @@IDENTITY (так
> вроде, опять же если память не сбоит)

Я уже не раз приводил пример, когда это не проканает :)
Если нужно получить будущий ID на клиент до исполнения "активного DML".
Или такой скрипт:
insert into SUBJECTS (SBJ_NAME) values ("ООО Мавзолей"); insert into ADDRESS (SBJ_ID, ADR_CONTEXT) values (@@Identity, "Москва, Красная Площадь, 1"); insert into ACCOUNTS(SBJ_ID, ACC_NUMBER) values (???, "40702810500000000123");

А на сайбэйсе это сработало бы так:
insert into SUBJECTS (SBJ_NAME) select Get_Identity("SUBJECTS", 1), "ООО Мавзолей" from DUMMY; insert into ADDRESS (SBJ_ID, ADR_CONTEXT) select Get_Identity("SUBJECTS", 0), "Москва, Красная Площадь, 1" from DUMMY; insert into ACCOUNTS(SBJ_ID, ACC_NUMBER) select Get_Identity("SUBJECTS", 0), "40702810500000000123" from DUMMY;
Почти так же это отработало бы на IB/FB. Еще легче - на Оракле, а вот на MS SQL... :)

> Или такой скрипт:

А какие проблемы?
insert into SUBJECTS (SBJ_NAME) values ("ООО Мавзолей"); MyVar = @@Identity; insert into ADDRESS (SBJ_ID, ADR_CONTEXT) values (MyVar, "Москва, Красная Площадь, 1"); insert into ACCOUNTS(SBJ_ID, ACC_NUMBER) values (MyVar, "40702810500000000123");
И никаких ??? :)

> Если нужно получить будущий ID на клиент до исполнения "активного
> DML".

Зачем нужно? Многие говорят "мне нужно". А когда начинаешь разбирать его цель, оказывается, что это совсем и не нужно.

> Зачем нужно? Многие говорят "мне нужно". А когда начинаешь
> разбирать его цель, оказывается, что это совсем и не нужно.

Я щаз обосную, зачем мне это нужно. Но от специалистов по MS SQL сразу послышится их любимое "А какие проблемы? Хранимка это все разрулит!" :)
У них все разруливается ХП.

Так вот, если есть форма добавления составной сущности (напр. субъекта с его адресами, счетами, паспортами, лицензиями и мн. др.) то часто возникает необходимость сначала снабдить все связанные наборы данных окончательным значением внешнего ключа. Вот тогда-то и помогает select Get_Identity("SUBJECTS", 1)

> возникает необходимость сначала снабдить все связанные наборы
> данных окончательным значением внешнего ключа.

Т.е. ты сначала создаешь запись ссылающуюся по сути на запись справочника, а потом саму эту запись? А проверка целостности (foreign key constraint) что отсутствует?

> часто возникает необходимость

извини, но ни разу не возникало такой необходимости. Сначала запись в справочнике, а потом уже детали. А если должны быть они либо вместе добавлены, либо отменены, то есть на это транзакции, commit и rollback. Ну и хранимки.

> Fay © (13.12.05 16:47) [31]
> Данные несколько устарели. В 2005 можно работать с версиями.

Я в курсе. Только пока не слышал ни одного объективного отзыва, можно ли вообще с ним работать. Если окажется, что можно - я без внутреннего содрогания включу его в свой список СУБД "к применению". Но пока мне хватает того, что есть.

> В 2005 можно работать с версиями

А какие уровни изолированности транзакции они там реализовали?

Нужен аналог "...TABLE_1 left outer join (TABLE_2, TABLE_3) on .. Найти похожие ветки