Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 8 9 10 11 12 13 14 15 [16] 17   вперед  Ctrl
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Pi
Member

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


1.
delete from parented   
    start with parent_id = parented_deleting.id 
    connect by prior id = parent_id;
напрямую не пройдет, а вот
delete from parented 
 where id in 
  (select id from parented   
    start with parent_id = parented_deleting.id 
    connect by prior id = parent_id
    );
работает.

2. Временную таблицу я лично использовал потому, что в Oracle триггер на строку работает как короткая транзакция, а потому не имеет права обращаться к другим строкам таблицы. Тем более удалять их.
1 ноя 04, 17:47    [1076002]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
SergSuper

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

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

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

Вот то, что нет в Оракле рекурсивных запросов, пока мне не ясно. Что это значит? Появятся они или нет? И на сколько повысится выразительная сила запросов. Может ASCRUS приведет пример для прояснения. У Оракла в 8 версии не было JOIN, а в 9 появились. Может так будет и с рекурсивными, если они есть в стандартах SQL. Однако, у Оракла есть аналитические функции, некоторые из которых способны заменить самосоединения. Поэтому я тоже в этом духе предложу ASCRUS запрос, чтобы посмотреть как у него он будет вылядеть.
1 ноя 04, 19:44    [1076308]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Pi
Member

Откуда:
Сообщений: 278
vadiminfo
У Оракла в 8 версии не было JOIN, а в 9 появились.



У Оракла в 8 версии не было JOIN - синтаксиса (который для меня кажется корявым), а был свой - "=", "+=" и "=+". Свой, естественно, был уже давно, я не знаю даже с какой версии...
1 ноя 04, 20:30    [1076361]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Pi
Member

Откуда:
Сообщений: 278
А вот, кстати, вспомнилась проблема, связанная с join.

Создаю представление:
create view WrongJoin as
SELECT account.account_parent, account.account_description, expense_fact.*
FROM expense_fact 
  LEFT JOIN account ON expense_fact.account_id = account.account_parent

и теперь спрашиваю, сколько в ней записей:
select count(*) from WrongJoin
where account_parent is null
GO
select count(*) from WrongJoin
where account_parent is NOT null
GO
select count(*) from WrongJoin
GO
MS SQL Server 2000 SP3
1800
2400
4200

Получается, что сумма больше, чем сумма слагаемых....
Или я что-то упустил?
1 ноя 04, 20:57    [1076388]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Pi

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

Это не просто синтаксис соединения. В стандарте SQL1 не было внешних соединений. Но там было внутренне с "=". Так как потребность во внешних была очевидна, то производители СУБД пошли по пути более простого синтаксиса для потребителей. В Оракле "(+) =", "=(+)". В MS SQL для этого использовалась * причем с противополжным значением. Разработчики стандартов использут достижения производителей, и стараются по возможности использовать то, что уже есть. Но в вопросе с соединениями они проявили жесткость, и в SQL2 появился JOIN. Это более строгий синтаксис. Он отделяет условие на соединение от предолжения WHERE, и позволяет более строго определить порядок соединения. А без этого не всегда ясен результат был. В Оракле кроме того "(+) =", "=(+)" накладывает ограничения на использование в WHERE OR, по-моему. Я уже не говорю про FULL JOIN. Так или иначе испопользуя JOIN, меньше надо опасаться сюрпризов и тратить время на тестирование. Я теперь пишу с удовольствием JOIN и для внутренненго соединения (вместо "="). Мне кажется так легче читать запрос - явно указывается операция.
1 ноя 04, 21:23    [1076419]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Амимопроходил
Guest
USE pubs
GO
CREATE TABLE  accounts(id int not null , acc_description varchar(20) null)
GO 
CREATE TABLE expense_fact(acc_id int not null, value  int null)
GO
CREATE VIEW Right_Join as
  select a.id, a.acc_description, e.*
      from expense_fact e LEFT JOIN accounts a 
			ON e.acc_id = a.id
GO

insert into accounts(id, acc_description)
  select 1, 'Account 1'
  union all select 2, 'Account 2'

insert into expense_fact(acc_id, value)
  select 1, 10
  union all select 1, 20
  union all select 2, 30
  union all select 2, 40
  union all select 3, 50
  union all select 4, 60  
GO

SELECT count(*) from Right_Join where id is null
SELECT count(*) from Right_Join where id is not null
SELECT count(*) from Right_Join

GO
DROP TABLE accounts
GO
DROP TABLE expense_fact

результаты
2
4
6

select @@version

Microsoft SQL Server  7.00 - 7.00.699 (Intel X86) 
	May 21 1999 14:08:18 
	Copyright (c) 1988-1998 Microsoft Corporation
	Standard Edition on Windows NT 4.0 (Build 1381: Service Pack 6)

на

Microsoft SQL Server  2000 - 8.00.534 (Intel X86) 
	Nov 19 2001 13:23:50 
	Copyright (c) 1988-2000 Microsoft Corporation
	Enterprise Edition on Windows NT 5.0 (Build 2195: Service Pack 3)

точно такой же результат, что неудивительно ))
2 ноя 04, 08:18    [1076733]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
DmitryV
Member

Откуда: Москва
Сообщений: 311
Pi
А вот, кстати, вспомнилась проблема, связанная с join.
MS SQL Server 2000 SP3
1800
2400
4200

Получается, что сумма больше, чем сумма слагаемых....
Или я что-то упустил?


Может я чего-то не понимаю, но 1800+2400=4200. Где я ошибся? ;-)
2 ноя 04, 09:38    [1076842]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
vadiminfo
В Оракле кроме того "(+) =", "=(+)" накладывает ограничения на использование в WHERE OR, по-моему. Я уже не говорю про FULL JOIN.


Угу, там много ограничений было.

vadiminfo
Так или иначе испопользуя JOIN, меньше надо опасаться сюрпризов и тратить время на тестирование.



Мне шибко поплохело, когда я на Оракле выполнил вот это:

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

No comments. Потом полезли глюки из оптимизатора, от вывернутых наизнанку планов до неправильных результатов запроса. В общем, весело там у них с явными джойнами...
2 ноя 04, 14:11    [1077925]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
NewYear
Member

Откуда: Большой адронный коллайдер
Сообщений: 2203
db2

C:\>db2 select * from sysibm.sysdummy1 d1 left join sysibm.sysdummy1 d2 on 1 = 0


IBMREQD IBMREQD
------- -------
Y -

1 record(s) selected.



oracle

select * from dual d1 left join dual d2 on 1 = 0
/


строки не выбраны
2 ноя 04, 15:13    [1078097]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Pi
Member

Откуда:
Сообщений: 278
DmitryV
Pi
А вот, кстати, вспомнилась проблема, связанная с join.
MS SQL Server 2000 SP3
1800
2400
4200

Получается, что сумма больше, чем сумма слагаемых....
Или я что-то упустил?


Может я чего-то не понимаю, но 1800+2400=4200. Где я ошибся? ;-)


Вчера вечером я был уверен, что 4200 - 2400 = 2400... Sorry!

Вредно сразу после выборов выходить на работу...
2 ноя 04, 15:13    [1078100]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
NewYear

db2
C:\>db2 select * from sysibm.sysdummy1 d1 left join sysibm.sysdummy1 d2 on 1 = 0
IBMREQD IBMREQD------- -------Y - 1 record(s) selected.

oracle
select * from dual d1 left join dual d2 on 1 = 0
/
строки не выбраны

Интересный вопрос.
Порылся в лит-ре чтобы понять, что же должен вернуть запрос с JOIN, если в условии на соединение нет ссылок на столбцы и значение FALSE. Ничего не нашел. Интуитивно думал, что тоже что и в db2, но раз в Оракле иначе, то теперь и не знаю.
Если написать условие со ссылками на столбцы и через and добавить 1 = 0, то последнее не влияет на результат. И вроде ему там не место, а место в where.
Так же, вроде, не влияет перенос из where и других условий в on. т.е. как будто их нет там.
Однажды не выспался и очень торопился и втюхал через and условие отбора в on вместо того, чтобы вставить в where. И никак не мого понять что за результат. Только через пол часа въехал. Хотел с тех пор повнимательнее разобраться с этим, но руки не доходили. И вот теперь здесь подняли этот вопрос. Интересно все это.
2 ноя 04, 23:20    [1079073]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Если написать условие со ссылками на столбцы и через and добавить 1 = 0, то последнее не влияет на результат. И вроде ему там не место, а место в where.

Почему это не место. По условию задачи как раз самое место - возвращаем записи из первой таблицы, со второй записей быть не должно, но ее поля в запросе присутствовать должны. И на ASA будет так же:
SELECT * 
FROM dummy d1 
  LEFT JOIN dummy d2 on 1 = 0;
результат:
dummy_coldummy_col
0(NULL)

по идее без разницы что за условие стоит в "on", задача оптимизатора по нему правильно соединить, желательно без лишних движений - в ASA например на такой запрос перед d2 будет поставлен "prefilter" с предикатом "false", который не позволит чего нибудь выбирать из d2:
( Plan [ Total Cost Estimate: .000511 ] 
( Left Outer NestedLoopsJoin[ TRUE ]
( TableScan ( DUMMY d1 ) )
( PreFilter [ FALSE ]
( TableScan ( DUMMY d2 ) )
)
)
)


Если Оракл не делает так же, то значит чего то у него не в порядке с JOIN-ами.
3 ноя 04, 06:28    [1079163]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
protector
Member

Откуда: Иваново, Россия
Сообщений: 600

ASCRUS

Если Оракл не делает так же, то значит чего то у него не в порядке с JOIN-ами.

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


Posted via ActualForum NNTP Server 1.1

3 ноя 04, 09:09    [1079324]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
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. Ни комитету по стандартам, ни самому Ораклу, в конце концов, синтаксис не понравился. В доке Оракл пишет про его недостатки.
Он был вызван стремлением не написать, чего то более сложного для пользователей, чем другие производители СУБД. И вряди он понятней - пишется в условиях отбора, тогда как соединение отличная от выборки операция в рел алгебре. Архиважная, впрочем как и выборка.
3 ноя 04, 10:38    [1079630]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
vadiminfo
Интуитивно то так. Но более формально, JOIN операция соединения, а ON условие на соединение. В соединении обязаны присутствать столбцы по которым осуществляется соединение в силу самого определения операции соединения в реляционной алгебре. Иначе что это за соединение?


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

vadiminfo
Тут вопрос в том как теперь должны распределяться условия между ON и WHERE.


Для внутренних джойнов это монопенисуально, результат будет единым. Для внешних распределение условий задает программист, ибо результаты могут быть шибко разные. Условие соединения уходит в ON, а фильтр на результат - в WHERE. И никакая самодеятельность со стороны сервера тут недопустима.

vadiminfo
Но то что опять один запрос вернет разные результаты в разных БД это важная для меня инфа. Здорово, что мы здесь обмениваеся такой инфой.


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

vadiminfo
Причем тут оптимизатор? Его дело выбрать лучший алгоритм выполни запроса. Т.е. он отвечает за то как извлечь лучше. А мы говорим про то что нужно извлечь.


Шаг влево/вправо в оптимизаторе чреват другими результатами запроса. По-моему, это очевидно.

protector
В Оракуле всё в порядке с джойнами, только с оракловыми, а с явными что-то не то.


Именно. Причем сильно не то. Особенно с внешними.
3 ноя 04, 11:23    [1079860]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
vadiminfo
Интуитивно то так. Но более формально, JOIN операция соединения, а ON условие на соединение.

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

Именно поэтому мне не нравится синтаксис join-ов; он нарушает базовую идею.

P.S. Из веселого - в Oracle Warehouse Builder разрешен синтаксис full outer join через (+). Там парсер отлавливает эту ситуацию и автоматически конвертирует в явный join.
3 ноя 04, 11:28    [1079894]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

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

вернет

dummy dummy
Х -

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

В ASA для оптимизатора условие в ON - это условие на соединение, условие в WHERE - условие на фильтрацию результата соединения. Что будет стоять в том или этом условии ему до лампочки, хоть константа, хоть соединения полей других таблиц. А оптимизатор очень даже при чем - я то пишу условие как мне удобней писать, а уже при выполнении запроса, если посмотреть его план не факт, что оптимизатор не изменит соединения таблиц, выкинет лишние таблицы и условия или даже их переделает (упросит булевые соединения скобок AND и OR или перегруппирует их, если возможно без потери смысла). Например, только вчера у меня в запросе такого плана:
SELECT *
FROM Table1 t1
  INNER JOIN Table2 t2 ON t1.id = t2.id AND t2.flag2 = 1
WHERE t1.flag1 = 1
я увидел в плане запроса соединение таблиц:
t1.id = t2.id AND t1.flag1 = t2.flag2
это при том, что flag1 никакого отношения к flag2 то собственно говоря не имеет. Я страшно удивился, но вроде все как выходило в данном случае верно - по текущему плану запросов ему было легче соединять column-to-column используя статистику, тем более что у обоих был тип bit, чем накладывать на каждую таблицу предикат сравнения флага с единичкой. Взял и поменял условие flag2 = 0 и он тут же в плане запросов разложил все на предикаты по таблицам. Вот так вот - а я то уж грешным делом посмотрев на план запроса подумал, что уже проглючиваю и в запросах поля разной смысловой нагрузки соединяю :)
3 ноя 04, 11:31    [1079921]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
DimaR
Member

Откуда:
Сообщений: 1570
TO vadiminfo

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

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

отличается ли он смыслом от DB2 или sybase, не знаю, может кто раскажет?
3 ноя 04, 13:51    [1080577]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
DimaR

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

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

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

Синтаксис with в 9i к рекурсиям пока не имеет отношения. Надно что-то типа with recurcive. А ситаксис with в Оракле позволяет реализовать что-то типа отделения описания подзапросов и вызова в запросе оп имени определенному в предложении with. Т.е. если один подзапрос встречается много раз в запросе, то можно в with его описать, а потом вставлять имена пордзапроса. Т.е. пока это просто даленьешие средства структуризации запроса, а не управление чем-либо типа рекурсии.
3 ноя 04, 14:05    [1080641]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
dimitr

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

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

dimitr

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


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



dimitr

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



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

Шаг влево/вправо в оптимизаторе чреват другими результатами запроса. По-моему, это очевидно.

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


softwarer

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


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

2 ASCRUS
Для анализа запроса, его оптимизации - оптимизация и план выполнения запроса нужны. Чтобы понять как поняла СУБД и как его улучшить. Но когда мы пишем запрос, мы в праве ничего не знать о деталях реализации. Т.е. мы без оптимизатора должны знать что должен вернуть запрос. Другое дело если мы начнем сравнивать сами оптимизаторы в наших СУБД.
3 ноя 04, 14:51    [1080817]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
vadiminfo

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

Мне - это неважно. Мне важно, что я получил результат, совпадающий со спецификацией.

Впрочем, это как всегда - вопрос терминологии, вопрос "где провести границу".
3 ноя 04, 15:24    [1080968]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Alex.Czech
Guest
Не понял, о чем флуд, если в Oracle 9.2.0.5 по крайней мере я увидел вот что:

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

D D
- -
X

Багов в Оракле конечно хватает, но данный конкретный видимо поправили :)
3 ноя 04, 18:18    [1081700]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
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 или нестандартные (+).
3 ноя 04, 18:59    [1081800]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Alex.Czech
Guest
С FULL OUTER JOIN там вообще багов хватает, в т.ч. и в 9.2.0.5, мягко говоря... я портировал с MS SQL, я знаю :)
3 ноя 04, 23:58    [1082052]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
vadiminfo
Но это значит, что Вы выполнили последовательно две операции рел алгебры картезиан - декартово соединение и выбора.

Нет. Это значит, что я продекларировал ограничение. А уж сервер выберет, какими операциями его реализовывать.

P.S. Имхо мы ходим по кругу в споре о вкусах.

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

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

vadiminfo
Так или иначе должен быть выбор явный JOIN или нестандартные (+).

Хм. Скажем так, для опытного разработчика, безусловно, лучше наличие обеих фич и возможность выбора. Но при гипотетическом выборе между диалектом, поддерживающим только LEFT|RIGHT JOIN и диалектом, поддерживающим только (+), лично я бы предпочел второй.
4 ноя 04, 11:00    [1082762]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 8 9 10 11 12 13 14 15 [16] 17   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить