А с таким запросом как?

← →
}|{yk © (2004-04-19 14:20) [0]

В оракле делаю так
SELECT a.set_id, a.mem_id, a.mem_pid, b.mem_name
FROM cust1_tree a,cust1 b,cust1 c
where a.mem_id=b.mem_id and a.mem_pid=c.mem_id(+)
order by a.mem_pid,a.mem_order

(+) - чтобы выводились и корневые элементы, не имеющие родителей
(+) в Interbase нет, чем его можно заменить?

← →
Danilka © (2004-04-19 14:26) [1]

outer join. вообще-то в документашке по ороклу так и написано, что (+) это и есть outer join :))

← →
Соловьев © (2004-04-19 14:27) [2]

> }|{yk © (19.04.04 14:20)

как ты различаешь корни? у меня там в родителе NULL - вот я и ставлю условие чтобы и эти выводить
и еще раз - http://www.ibase.ru/develop.htm

← →
}|{yk © (2004-04-19 14:31) [3]

а как тут outer join применишь?

← →
Danilka © (2004-04-19 14:32) [4]

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

← →
Danilka © (2004-04-19 14:34) [5]

[3] }|{yk © (19.04.04 14:31)
честно говоря, лениво запрос писать - я еще сам напрягаюсь с этими джойнами, да и проверить под рукой базы фиребирдовской нет. :))

← →
Johnmen © (2004-04-19 14:43) [6]

...FROM A LEFT JOIN B ON A.ID=B.ID...
соответствует
...FROM A,B WHERE A.ID(+)=B.ID...

И вообще, это Оракул извратился над стандартным синтаксисом...

← →
Vlad © (2004-04-19 14:52) [7]

> И вообще, это Оракул извратился над стандартным синтаксисом...

Но в Оракуле так же оставлен и стандартный синтаксис

← →
Курдль © (2004-04-19 14:53) [8]

> И вообще, это Оракул извратился над стандартным синтаксисом...

Иногда стандартного синтаксиса не хватает. Sybase, например, для этих целей использует TransactSQL, в нем бы числилось WHERE A.ID *= B.ID
Но это не для того, чтобы помочь ленивым в записи "...outer join", - просто многие условия стандартным языком не описать.
Например:
WHERE A.ID(+)= B.ID AND B.ID(+)= C.ID AND C.ID(+)= D.ID AND D.ID(+)= E.ID AND E.ID(+)= F.ID

← →
Johnmen © (2004-04-19 14:54) [9]

>Но в Оракуле так же оставлен и стандартный синтаксис

В 8 версии разве есть JOIN ?
:)

← →
}|{yk © (2004-04-19 14:56) [10]

Дык... Непонятно
как же это-то запрос переписать под Interbase?
Ведь здесь хотя и объединяются 2 таблицы, но соединение не 1, а 2 - в таблице cust1 хранятся объекты, а в cust1_tree - связи

← →
sniknik © (2004-04-19 14:58) [11]

Johnmen © (19.04.04 14:43) [6]
> И вообще, это Оракул извратился над стандартным синтаксисом...
не только он в Perwasive вместо LEFT JOIN есть =+ (или наоборот +=), почти оракул только без скобочек. ;)

← →
Vlad © (2004-04-19 14:59) [12]

> Johnmen © (19.04.04 14:54) [9]

Есть и join и outer join :-)

← →
Johnmen © (2004-04-19 15:00) [13]

>многие условия стандартным языком не описать.
>Например:
>WHERE A.ID(+)= B.ID
>AND B.ID(+)= C.ID
>AND C.ID(+)= D.ID
>AND D.ID(+)= E.ID
>AND E.ID(+)= F.ID

FROM A
LEFT JOIN B ON B.ID= A.ID
LEFT JOIN C ON C.ID= B.ID
LEFT JOIN D ON D.ID= C.ID
LEFT JOIN E ON E.ID= D.ID
LEFT JOIN F ON F.ID= E.ID
:)

← →
DenK_vrtz © (2004-04-19 15:02) [14]

с девятки есть join и outer join :)

← →
Johnmen © (2004-04-19 15:02) [15]

>Vlad © (19.04.04 14:59) [12]
>Есть и join и outer join :-)

По-моему, ты вводишь старого склеротика в заблуждение...(<=8 версия)
:)

← →
Курдль © (2004-04-19 15:05) [16]

> но соединение не 1, а 2 - в таблице cust1 хранятся объекты,
> а в cust1_tree - связи

Вы чего-то не договариваете! Если условие в исходном запросе не усечено:
where a.mem_id=b.mem_id and a.mem_pid=c.mem_id(+) order by a.mem_pid,a.mem_order
то содержать лишнюю таблицу для поддержки древовидной связи бессмысленно - проще сделать свяь в единственной таблице один-ко-многим на саму себя.

← →
Danilka © (2004-04-19 15:05) [17]

[15] Johnmen © (19.04.04 15:02)
в восьмерке на самом деле нет.

[6] Johnmen © (19.04.04 14:43)
на самом деле этого достаточно? может left outer join?

← →
}|{yk © (2004-04-19 15:11) [18]

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

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

Кстати, если Ваша цель построить "дерево", то какие дальнейшие планы? Ну, получите набор данных вида:
а1 - в2
а1 - в3
а2 - в5
а2 - в6
а3 - в7
а3 - в8
а9 - в10
...
И что дальше? На клиенте будете дерево строить? Так не лучше ли просто взять 2 НД - cust1_tree и cust1, чтобы просто построить дерево в памяти и не мучать сервер многократным выбором одних и тех же значений?

Вот так вот
SELECT a.set_id, a.mem_id, a.mem_pid, b.mem_name CHILD_NAME,c.mem_name PARENT_NAME
FROM cust1_tree a
left join cust1 b
ON (a.mem_id=b.mem_id)
left join cust1 c
ON (a.mem_pid=c.mem_id)
Работает правильно

когда я построю такле дерево, то 1 (!) запросом я построю дерево, и построение его на клиенте будет занимать только 1 проход по созданному запросу

хм... действительно, поглядел в интернете, везде написано что left join в 8i не поддерживается. Однако у меня довольно очетливо осталось в памяти, что сам лично пользовался такой конструкцией на 8-м Оракле.... Переутомился наверное....

> 1 (!) запросом я построю дерево

Вы не построите дерево! А лишь список связей "предок-потомок". Причем размер НД увеличится, кратно степени иерархии.

А с таким запросом как? Найти похожие ветки