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

Там не временная таблица, а ассоциативный массив был. Я потом исправил пример softwarer, чтобы убрать и массив и циклы. Но в Оракле нет рекурсивных запросов, а есть иерархические. Он и был использован. У softwarer не было времени на тестирование когда он писал, и поэтому он написал вариант, который точно сработает. А с иерархическим запросом были опасения насчет констрейнов, так он мог удалять не в том порядке. softwarer согласился, что это исправление должно работать. Т.е. в данном примере то сработал, а вот во всех случаях возможно пришлось бы проверять.
Ассоциативный массив - это таблица PL/SQL (он так и назывался в 7 версии). Т.е. это таблица не является объектом БД, это переменная PL/SQL.

А временная таблица в Оракле объект БД, и хранится в схеме. Часто народ вместо массивов ее применяет в подобных случаях (сам не видел, но вычитал в инете про это), но кажется это было бы не рационально. Она подходит для каких-то больших вычислений, если выразительной силы запросов не хватает, чтобы держать там промежуточный результат. В Опкле ее содержание может храниться в пределах сессии или транзакции, и поэтому пользователи или транзакции не мешают друг другу. Я когда-то делал систему на Access. Там сила запросов слабовата. Вполть до того, что в какой-то момент система говорит, что выражение слишком сложное. Там нет временных таблиц. И для промежеточных результатов пришлось делать обычные. Но эти результаты видны во всех сессиях. Пользователи мешают друг другу. Пришлось делать на клиенте по маленькой БД для этих таблиц и присоединять их к основной.

Вот то, что нет в Оракле рекурсивных запросов, пока мне не ясно. Что это значит? Появятся они или нет? И на сколько повысится выразительная сила запросов. Может ASCRUS приведет пример для прояснения. У Оракла в 8 версии не было JOIN, а в 9 появились. Может так будет и с рекурсивными, если они есть в стандартах SQL. Однако, у Оракла есть аналитические функции, некоторые из которых способны заменить самосоединения. Поэтому я тоже в этом духе предложу ASCRUS запрос, чтобы посмотреть как у него он будет вылядеть.

Pi
У Оракла в 8 версии не было JOIN - синтаксиса (который для меня кажется корявым), а был свой - "=", "+=" и "=+". Свой, естественно, был уже давно, я не знаю даже с какой версии...

Это не просто синтаксис соединения. В стандарте SQL1 не было внешних соединений. Но там было внутренне с "=". Так как потребность во внешних была очевидна, то производители СУБД пошли по пути более простого синтаксиса для потребителей. В Оракле "(+) =", "=(+)". В MS SQL для этого использовалась * причем с противополжным значением. Разработчики стандартов использут достижения производителей, и стараются по возможности использовать то, что уже есть. Но в вопросе с соединениями они проявили жесткость, и в SQL2 появился JOIN. Это более строгий синтаксис. Он отделяет условие на соединение от предолжения WHERE, и позволяет более строго определить порядок соединения. А без этого не всегда ясен результат был. В Оракле кроме того "(+) =", "=(+)" накладывает ограничения на использование в WHERE OR, по-моему. Я уже не говорю про FULL JOIN. Так или иначе испопользуя JOIN, меньше надо опасаться сюрпризов и тратить время на тестирование. Я теперь пишу с удовольствием JOIN и для внутренненго соединения (вместо "="). Мне кажется так легче читать запрос - явно указывается операция.

NewYear
db2
IBMREQD IBMREQD------- -------Y - 1 record(s) selected.

oracle
строки не выбраны

Интересный вопрос.
Порылся в лит-ре чтобы понять, что же должен вернуть запрос с JOIN, если в условии на соединение нет ссылок на столбцы и значение FALSE. Ничего не нашел. Интуитивно думал, что тоже что и в db2, но раз в Оракле иначе, то теперь и не знаю.
Если написать условие со ссылками на столбцы и через and добавить 1 = 0, то последнее не влияет на результат. И вроде ему там не место, а место в where.
Так же, вроде, не влияет перенос из where и других условий в on. т.е. как будто их нет там.
Однажды не выспался и очень торопился и втюхал через and условие отбора в on вместо того, чтобы вставить в where. И никак не мого понять что за результат. Только через пол часа въехал. Хотел с тех пор повнимательнее разобраться с этим, но руки не доходили. И вот теперь здесь подняли этот вопрос. Интересно все это.

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

Интуитивно то так. Но более формально, JOIN операция соединения, а ON условие на соединение. В соединении обязаны присутствать столбцы по которым осуществляется соединение в силу самого определения операции соединения в реляционной алгебре. Иначе что это за соединение? Есть декартово произведение, там нет условия на соединение. Для выборки условия записываются в WHERE. Тут вопрос в том как теперь должны распеределяться условия между ON и WHERE.
Но то что опять один запрос вернет разные результаты в разных БД это важная для меня инфа. Здорово, что мы здесь обмениваеся такой инфой.
ASCRUS
по идее без разницы что за условие стоит в "on", задача оптимизатора по нему правильно соединить, желательно без лишних движений - в ASA например на такой запрос перед d2 будет поставлен "prefilter" с предикатом "false", который не позволит чего нибудь выбирать из d2:

Причем тут оптимизатор? Его дело выбрать лучший алгоритм выполни запроса.
Т.е. он отвечает за то как извлечь лучше. А мы говорим про то что нужно извлечь.
Такой результат как у Вас можно извлечь в Оракле, но классическими для соединений условиями - явное указание столбцов, по которым должно быть соединение, наприер
select * from dual d1 left join dual d2 on d1.dummy = d2.dummy || d2.dummy

вернет

dummy dummy
Х -

Но вопрос до конца не ясен. Нужно понять достоинство и недостатки того как работают условия выборки в условии на сединение.


protector
В Оракуле всё в порядке с джойнами, только с оракловыми, а с явными что-то не то. К тому-же нарушается совместимость, а многие до сих пор сидят на восьмерке и даже на семерке. Кстати, что будет, если в укзать якный джойн и обычный оракловый в одном запросе. Кстати мне синтаксис с (+) нравится больше. Удобней и понятней ИМХО.


На (+) есть ограничения, не ясен порядок, нет FULL JOIN. Ни комитету по стандартам, ни самому Ораклу, в конце концов, синтаксис не понравился. В доке Оракл пишет про его недостатки.
Он был вызван стремлением не написать, чего то более сложного для пользователей, чем другие производители СУБД. И вряди он понятней - пишется в условиях отбора, тогда как соединение отличная от выборки операция в рел алгебре. Архиважная, впрочем как и выборка.

DimaR
Вот то, что нет в Оракле рекурсивных запросов, пока мне не ясно. Что это значит? Появятся они или нет?

Если имеется в виду синтаксис with, то он уже давно есть, начиная с 9i.

отличается ли он смыслом от DB2 или sybase, не знаю, может кто раскажет?

Синтаксис with в 9i к рекурсиям пока не имеет отношения. Надно что-то типа with recurcive. А ситаксис with в Оракле позволяет реализовать что-то типа отделения описания подзапросов и вызова в запросе оп имени определенному в предложении with. Т.е. если один подзапрос встречается много раз в запросе, то можно в with его описать, а потом вставлять имена пордзапроса. Т.е. пока это просто даленьешие средства структуризации запроса, а не управление чем-либо типа рекурсии.

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

Им еще рано уходить на отдых, пусть работают. А вот спецификацию я пока не нашел. Ограничение то отсутствует, иначе бы ругалось. А вот как понимать условие на соединение, если нет про описание про то по каким столбцам должно происходить соединение? Это другое.

dimitr
Условие соединения уходит в ON, а фильтр на результат - в WHERE. И никакая самодеятельность со стороны сервера тут недопустима.


Уходит то оно уходит. Вопрс как уходит. И почему самодеятельность сервера? Возможно, так и задумано. Мы же еще не нашли реальных аргументов в пользу того или другого. Пока интуиция работает.



dimitr
Но я уверен, что это нельзя относить к "разным результатам в разных БД", ибо налицо явный баг и Оракл его как пить дать исправит. Ибо с своей трактовке ON-предиката он чудовищно одинок в толпе прочих СУБД :-)



Если уверенность основана на том что это баг, то она, возможно, преждевременна. Я проверял и на других запросах. Везде работает так же, а в доке ничего нет по данному вопросу. Баг - если результат не тот, что должен быть в доке. А так пока не ясно баг это или нет. А я и в книгах копал. Пока не нашел прояснений.
То что Оракл будет подгонять тоже не ясно. Ведь тогда могут перестать работать уже написанные по старому запросы, в разработанных системах.
dimitr
Шаг влево/вправо в оптимизаторе чреват другими результатами запроса. По-моему, это очевидно.

При чем тут шаги в оптимизаторе? Его дело оптимизировать. Он может вообще переписать запрос по другому, но чтобы тот возвращал, то что есть в исходном запросе. Это уже вопросы реализации запроса.
Мы же не оптимизаторы сравниваем, а сами запросы.


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


Все-таки SQL - язык БД и предназначен для реализации модели данных, в том числе и рел алгебры. Для ухода от операций предназначены исчисления доменов или кортежей. Декларативность лишь означает, что нет алгоритмических процедур для реализации операций, а просто описываются алгебраические операции, например, соединение. Т.е. он описывает алгебраические операции (а не процедуры и алгоритмы на процедурном языке), которые нужно выполнить, чтобы получить результат. А СУБД их выполняет. И если Вы пишите (+), то Вы предполагаете, что алгебраическая операция "внешнее соединение" ассоциативна, т.е. не зависит от порядка выполнения, а не уход от от этой операции. А всегда она ассоциативна? В JOIN есть возможность явно задать порядок соединений.

2 ASCRUS
Для анализа запроса, его оптимизации - оптимизация и план выполнения запроса нужны. Чтобы понять как поняла СУБД и как его улучшить. Но когда мы пишем запрос, мы в праве ничего не знать о деталях реализации. Т.е. мы без оптимизатора должны знать что должен вернуть запрос. Другое дело если мы начнем сравнивать сами оптимизаторы в наших СУБД.

Alex.Czech
в Oracle 9.2.0.5 по крайней мере я увидел вот что:

SQL> select * from dual d1 left join dual d2 on 1 = 0;

D D
- -
X


Значит все-таки то был баг в 9.2.0.1.0. Там на самом деле есть еще гадский баг с FULL JOIN. Вообще отпадает на нем серверный процесс. Причем коварно, до определенной сложности запроса все нормально, добавил order by и обрыв коммуникаций. В 9.2.0.5 говорят нет уже.




автор
С моей точки зрения, когда я пишу a.id = b.id, я накладываю некоторое ограничение на результирующую выборку - то есть из картезиана исходных данных оставляю только те, которые соответствуют некоторому условию. Само условие может быть любым, в том числе достаточно сложным.



Но это значит, что Вы выполнили последовательно две операции рел алгебры картезиан - декартово соединение и выбора. Но есть и различные другие виды соединений в алгебре. И ими легче мыслить, а потом реализовать на SQL. Одна операция вместо двух: соединение вместо картезиана и выборки. В этом может быть еще больше декларативности, потому что не надо разбивать на две операции и кроме того, это уже похоже на алгоритм выполнения соединения. Т.е. получается вопрос о сводимости соединений к картезиану и выборки, и о том охота ли сводить, когда можно строго прописать само соединение. Тем более когда участвует много таблов в соединении там может играть роль и порядок соединений.
Так или иначе должен быть выбор явный JOIN или нестандартные (+).