iLLer wrote:

> Хм. Если спичка лезет в замочную скважину, это еще не значит, что это ключ.
> Если оптимизатор пропускает такую конструкцию, значит он ОДНОЗНАЧНО
> считает, что сначала перемножит две таблицы A и B, и только после этого
> приступает к рассмотрению возможностей подсоединения третьей, C.

Форма записи SQL-запроса никак не связана со способом его обработки.
Ну и стало быть все остальные "выводы" также неоправданы.
Posted via ActualForum NNTP Server 1.4

iLLer wrote:

> Наверно Вы хотели сказать, что форма записи не должна определять способ
> выполнения. Конечно, в теории это так и есть.

Это и на практике такое есть.

Я говорил лишь про
> сервера, которые глотают такую фигню. И факт этого глотания говорит лишь
> об одном, что некорректность соединения B и C сервер может не заметить
> только в одном случае, когда он априори и не пытается проанализировать
> эту возможность. В противном случае он бы возвращал ошибку. А раз не
> возвращает, значит подход к анализу усеченный.

Что-то очень мало смысла в вышеприведённом.

В чём по-твоему заключается "некорректность соединения B и C" ?

> Я правильно Вас понимаю, что Вы допускаете возможность существования
> некоего гипотетического сервера, который бы с одной стороны молча
> принимал такую конструкцию, а с другой, при построении плана выполнения
> заценивал все возможные стоимости включая подход сначала B и C, а потом
> перемножение с A?!

Я не допускаю, я просто знаю, что они есть.

И, очевидно, натыкаясь на ошибку тупо отбрасывал этот
> план с неудавшейся стоимостью, а оставлял тот, который позволил бы
> выполнить запрос?

Отбрасывает сервер какие-то планы или нет -- никак не связано
с способом записи JOIN-а в запросе.

Что

FROM A,B left outer join C on C.a=A.b
WHERE A.c=B.d

что

FROM A
join B on A.c=B.d
left outer join C on C.a=A.b
Posted via ActualForum NNTP Server 1.4

iLLer wrote:

> Может Вы тоже не заметили "прикола"?
> Хорошо. Гипотетический сервер существует. Представим, что мы это он.
> Попытаемся заценить стоимость обработки запроса в случае, когда мы
> сначала хотим пересечь B и C, и только потом A.

A нельзя после C. C -- внутренняя.

Можно только A, B, C
либо B, A, C
либо A, C, B

> вообще не знаете что такое A.b, т.к. отложили A на потом! Оценка
> невозможна, т.к. на соединение B и C нельзя наложить условие "C.a=A.b".

Здесь нет никакой ошибки синтаксиса. По семантике операции left outer join
A должно быть перед С. А вот при чём тут B, или как его JOIN записан --
не понятно.
Posted via ActualForum NNTP Server 1.4

iLLer wrote:

> Я кажется понял на что Вы намекаете. Т.е., следуя Вашим утверждениям,
> следующий запрос уже имеет ошибку синтаксиса, т.к. A упоминается не
> перед, а после C?!
>
> SELECT *
> FROM B left outer join C on C.a=A.b,A
> WHERE A.c=B.d

Я не знаю, можно ли в конкретно этой СУБД так писать.
Давайте предположим, что можно. Тогда никакой ошибки тут не будет.


> Но, позвольте, разве от изменения порядка следования перечисляемых
> что-то меняется?

Нет.

Так скажем, должно ли меняться?
нет.

Сдается мне, что по
> стандарту SQL такого быть не должно.

Чего ?
Posted via ActualForum NNTP Server 1.4