Intersect and other into FB/IB

[Flot]

Подскажите пожалуйста, есть ли во встроенном SQL InterBase-а или FireBird-а команды пересечения/вычитания запросов. В стандарте SQL эти команды декларируются, но в IB5 не поддерживаются. Сейчас встал вопрос о переходе на более новую (чем IB5) платформу и наличие возможности получения пересечения/вычитания запросов будет немаловажным при решении, на что переходить.

Спасибо всем, кто откликнется.

[Flot]

P.S. Чуть расширю свой вопрос -- реализована ли возможность таких запросов на других платформах.

[Oldy]

Не понял чего Вы хотите, поэтому отсылаю к документации:
FireBrid 1.0
http://prdownloads.sourceforge.net/firebird/Firebird_v1_ReleaseNotes.pdf

FireBird 1.5
http://www.ibphoenix.com/downloads/Firebird_v15.108_ReleaseNotes.pdf

Yaffil
http://yaffil.ibase.ru/download/yaffil885.exe (ReleaseNotes внутри Self-архива)

[Flot]

Документацию на FB 1.5 я смотрел и там этого не нашел. Возможно я был невнимателен Возможно это есть в IB 7. Возможно это реализовано на других платформах.

А суть вопроса в следующем. Есть 2 запроса, например:
Select * from Table1
и
Select * from Table2
(для простоты будем считать, что таблицы имеют одинаковую структуру).
Тогда
Select * from Table1
Union
Select * from Table2
дает объединение таблиц.
В стандарте SQL кроме объединения прописана возможность найти пересечение запросов:
Select * from Table1
Intersect
Select * from Table2
(что то типа, возможно синтаксис другой).
Такой запрос должен давать выборку записей входящих сразу в обе таблицы.
В принципе, все остальное можно построить из этих двух операций.

Мой вопрос именно о том, есть ли в ID/FB реализация аналога Intersect. И дополнение -- возможно это реализовано на других платформах (хоть на Oracle я надеюсь это есть ).

[Flot]

Глянул документацию на Yaffil (спасибо за ссылки). К сожалению, как и в FB возможности пересечения запросов не нашел. Странно, что такая полезная возможность (особенно при всякого рода конвертациях) самого SQL-я не поддерживается. Мне казалось, что техническая реализация этого не сложнее реализации Union.

По ходу родился еще один вопрос. В описании Yaffil нашел, что a==b обращается в True и тогда, когда a=null, b=null. есть ли такое в FB/IB? Эта особеннсость совместно с Join пусть криво, но позволяет эмулировать Intersect.

[Oldy]

Попробуте задать ваш вопрос в этой конференции:
news://forums.demo.ru/epsylon.public.interbase
В ней постоянно присутствуют разработчики FB и Yaffil. Может быть сумеете договориться с ними, чтобы они включили интересующие вас возможности в следующие сборку или версию, или хотя-бы в виш-лист.

[x77]

Flot, в явном виде такой возможности нет. но получить записи, входящие в обе таблицы, по некоему условию (равенство нескольких или всех полей) можно элементарно обычным where. видимо поэтому разработчики и не заморачивались сомнительными с точки зрения чистого SQL альтернативами...

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

что, жизненно важно, чтобы это делалось именно отдельным оператором уровня union?

[Flot]

Спасибо за ответы.

x77, что касается "жизненой важности", то единственное желание -- получить пересечение ОДНИМ SQL-ЗАПРОСОМ. Несмотря на ваше утверждение про возможность реализации пересечения кортежей оператором where (или join, как это делаю сейчас я) позвольте с вами не согласиться. Все хорошо и прекрасно (правдо громоздко и неудобно, если пересечение необходимо проводить по нескольким десятком полей) лишь до тех пор, пока поля сравнения не содержат значений null. Как только это происходит, в запросе эмулирующем пересечении с помощью where или join пропадут записи, содержащие null в полях сравнения (что связано с тем, что выражение типа null=null не обращается в True, и именно поэтому меня так порадовала возможность избежать этого в Yaffil [о чем я говорил в предидущем посте]). Ну и плюс к этому, чисто методически логично базовые понятия SQL (как вы совершенно правильно заметили) разработчикам реализовывать одной командой, а не предлагать пользователям придумывать колесо по этому поводу (хотя этот коммент больше риторический).

[x77]

"null=null в ТRUE" - правильно. есть масса способов реализовать сравнение корректно, начиная от забивки предустановленных "нуловых" значений, и заканчивая обычными операторами сравнения: (a1 is null) and (a2 is null). вопрос о том, что удобнее - писать два запроса или один с разветвлённым where clause мне лично представляется спорным. не думаю, что в общем виде на него можно ответить, надо рассматривать конкретные примеры.

[Flot]

Представьте себе, x77, что вы конвертите с 5-ток - другой таблиц, каждая из которых имеет с пару - другую десятков полей. И вы не имеете права забивать в них null-ы (ну скажем по причине того, что null в них несет некую информацию) ... ладно, пусть не так сложно
Пусть есть 2 таблицы, в которых по 2 поля A(a1, a2) и B(b1, b2). Нужно найти их пересечение при условии, что в любое поле может принимать значение null. Да, наверное существует множество вариантов написать такой запрос. Мне на ум приходит лишь объединение 3-ех запросов, где последовательно сравниваются A и B при условии
1) a1 is not null and a2 is not null (сравнение по a1=b1 and a2=b2)
2) a1 is not null and a2 is null (сравнение по a1=b1)
3) a1 is null and a2 is not null (сравнение по a2=b2)
Так что, ТЕОРЕТИЧЕСИ такой запрос написать можно, но представьте себе, на что он будет похож при хотя бы 10 - 15-ти полях сравнения!
Поэтому, несмотря на принципиальную ТЕОРЕТИЧЕСКУЮ возможность написать такой запрос, его ПРАКТИЧЕСКОЕ использование вряд ли возможно при больших количествах полей сравнения. А по сути это означает отсутствие такой возможности.

[x77]

Flot, не согласен

как, по вашему, реализуется where? насколько я в курсе, пермножением матриц.

как будет реализовываться intersect? неужто как-то иначе? ведь там придётся учитывать те же самые нулы.

так в чём разница? в удобочитаемости? не самый важный критерий при выборе субд, imho.

[Flot]

x77, мы же используя Union (и where тоже ) не задумываемся о том, как оно функционирует внутри движка. Мы просто знаем, что будет на выходе. Программисты даже термин для этого придумали -- инкапсуляция (нехристи немытые, могли бы назвать 'концы в воду', например ). А если довести ваше утверждение до маразма, то тогда из SQL-я придется убрать много еще чего, сославшись, что все это можно построить из Select и where. И еще, не забывайте, x77, что все мы люди. А всем людям свойственно а) Лениться (писать большие скрипты) б) Ошибаться (при их написании) Так что молодцы мужики из команды Yaffil, что ввели оператор "==", который обрабатывает сравнение null-ов (хоть это и не повод на "дятла" переходить).

Я извиняюсь, но все же напомню (переформулировав) свой вопрос:

1) Есть ли в FB/IB команда пересечения запросов (надежда осталась вроде как только на IB7)
или
   а) хотя бы операции сравнения a=b -> True (при a=null, b=null)
2) В каких платформах эти особенности реализованы?

Спасибо.

[x77]

Flot,

1) нет
2) yaffil
3) DB2, Informix, Oracle.

[x77]

могу ещё добавить, что sql'92 реализован на нескольких уровнях. INTERSECT - это intermediate level, а большинство коммерческих продуктов не идут дальше entry level, справедливо (на мой взгляд - ) указывая, что оператор примитивным не является.

[x77]

имеется в виду, INTERSECT

[x77]

да, ещё subj поддерживается в PostgreSQL.

[Flot]

Спасибо, x77. Надо будет на счет Oracle подумать. ... И про Informix почитать.

[x77]

а Postgre - не нравится? как и у оракла, реализация SQL у него ближе к sql'99, а не 92. т.е., сия субд имеет наглость считать себя объектно ориентированной. Плюс великолепно живёт под линухом, легко прикручивается к PHP, и многое другое если же веб не нужен - обычная двух-звенка.

[Flot]

Про Postgre я не слышал почти ничего (ни плохого ни хорошего) Вот и прокинул его А в смысле администрирования он так же тяжел, как Oracle? Да и вообще то, если бы ни необходимость частых (и возможно изменчивых в смысле источника) конвертаций, то перешел бы на FB 1.5 и не думал бы. А так вот стал искать себе возможность жизнь облегчить.

Еще маленький вопрос, нет ли ссылок на документацию, где четко прописано, какие операторы SQL реализованы в FB 1.5? В той, что к нему прилагается я только то, что добавлено нашел (может все остальное в FB 1.0 есть?). А то методом "тыка" все как-то больше приходится обучаться (т.е. непосредственной проверкой операторов -- выполянться/не_выполняться). А что же это за обучение.

[x77]

собственно, те же, что и в IB 6.0.1.  что-то добавилось, конечно, но это есть в release_notes, http://www.ibase.ru/v6/Firebird_v15_ReleaseNotes1.htm, например.

ещё стоит порыться на firebirdsql.org и ibphoenix.com

[Flot]

Спасибо, x77, гляну.

[x77]

удачи