Не могу понять, как запрос работает (он работает), вот секция FROM:

FROM
	((Materiaal_T 
		INNER JOIN (Leveranciers_T 
			INNER JOIN (Handvat_T 
				INNER JOIN (OPDRUKBONS_T 
					LEFT JOIN Klantenadressen_T 
					ON OPDRUKBONS_T.Klantnummer=Klantenadressen_T.KlantNr)
				ON Handvat_T.IDnr=OPDRUKBONS_T.Handvat) 
			ON Leveranciers_T.IDnr=OPDRUKBONS_T.Leverancier)
		ON Materiaal_T.IDnr=OPDRUKBONS_T.Materiaal) 
	LEFT JOIN KLACHTEN_T 
	ON OPDRUKBONS_T.KooporderNr=KLACHTEN_T.KooporderNr)

не могу перевести это в привычный линейный вид, когда идёт джойн - условие джойн - условие, без этих вложенностей. Как преобразовать этот запрос?

Разобрался, как переделать:

FROM
OPDRUKBONS_T LEFT JOIN Klantenadressen_T 
	ON OPDRUKBONS_T.Klantnummer=Klantenadressen_T.KlantNr
JOIN Leveranciers_T 
	ON Leveranciers_T.IDnr=OPDRUKBONS_T.Leverancier
JOIN Handvat_T 
	ON Handvat_T.IDnr=OPDRUKBONS_T.Handvat
JOIN Materiaal_T 
	ON Materiaal_T.IDnr=OPDRUKBONS_T.Materiaal
LEFT JOIN KLACHTEN_T 
	ON OPDRUKBONS_T.KooporderNr=KLACHTEN_T.KooporderNr

только почему так оно раскрывается, я не понял.

Есть подозрение, что оптимизатор в нормальной ДБ делает в итоге из обоих запросов одно и то же.

Первый вариант (A + (B + (C + D))) + E
Твой вариант A + B + C + D + E

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

Ну да. В данном случае работа с MSSQL.

Не совсем так.
Если первый вариант: A join (B join (C join (D left join E))) left join F
второй: D left join E join B join C join A left join F.

Как полностью правило преобразования сформулировать?

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

Как полностью правило преобразования сформулировать?
------
Почти никак.
Конкретное построение будет базироваться не только на синтаксисе, но и на статистике.
Так что левый джойн может быть отдельным сканом, а может и вообще не сканится...
Я почти перестал смотреть как оно джойнится - накидал во вью что надо, сцепил как
подходит - с остальным, пока запрос не выпадет за пару минут, вообще не вожусь....
ЗЫ. У тебя что, как у меня - база грязная с нулами и без реляций? Зачем еще левый
джойн нужен?

Да. Только я уже закончил с этим проектом. Поправил запрошенные баги и сдал. Там из аксесса базу в проект притащили - полный пи###ц. Десятки полей в таблицах, километровые запросы...

он и в нормальных базах нередко нужен. Для вывода бездетных строк вместе со всеми. Особенно в репортинге.

из аксесса базу в проект притащили - полный пи###ц
-------
Это еще не писсец... Писсец - это у меня сейчас...
База... живет - непонятно сколько... но - в многопользовательской системе...
В смысле - не многоюзерской, а много раздельных лицензированных пользователей,
каждый со своими данными...
База - без реляций... Таблицы - без ключей... Поля - практически все с нуллами...
Сложных запросов, как таковых, практически нету... есть выборки из таблиц...
динамическим скл-ом... при этом откуда именно и что берется непонятно -
имена таблиц в запросах левые, пересчитываются vbscript'ом...
До недавнего времени требовали править код по живой системе... через месяц
дошло, что еще немного и задачу они просто не соберут...
АСПшный код... полный звизденец... управление страницей выполняется не через
операции на странице, а через загрузку файлов... что намешано в файлах - мрак...
Одних определений коннектов к базе - штук 20-ть... не считая прописанных прямо
на странице...
Сегодня с одной страницы снес с полтора десятка включаемых файлов... и пяток
ссылок на жабий скрипт... пофиг - все пашет как и было...

Частично используется жабий скрипт... Это отдельная песТня.... Часто используется
загрузка и показ немодальной формы со стороннего АСП... Есть функция чтобы ее
загрузить и показать... точнее - несколько имплементаций одной и той же функции...
Сегодня задал поиск - штук 40 вариантов на трех сайтах...
Но это еще не все... вместо передачи параметров - в теле скрипта определяются
переменные... поменять на передачу параметров - нельзя... слишком много работы...
Днями надо было добавить "переменную-параметр"... добавил, проверил... свое...
все работает...
Вчера показывают - вот, поправили все другие страницы - на каждую вставили твою
"переменную-параметр"... потому как по другому не работало... - Но она там нафиг
не нужна - она нужна только на той группе которой Я занимался... - Ничего - мы ее
потом используем для другого параметра... :) - объясняю - не надо так делать -
сделайте одну переменную куда можно сложить что надо или оставить ее пустой
- в процедуре больше править ничего не надо будет... --- Сделали... переименовали
переменную, присвоили ноль... в функции - аккуратно собрали с строку с остальными...
И ничего - пишут код и даже что-то работает... Но вообще - мрачно... пиззенец...

Для вывода бездетных строк вместе со всеми. Особенно в репортинге.
------
Можно обойтись и без... вообще без джойна... В репортинге - сложнее,
но тоже можно...

И че, мигрировать пришлось?
Наша база тоже в полной жопе, но исправлять боятся.

Они перетащили аксессовую базу в мсскл, не знаю, как они перетаскивали, я сдал проект и x. с ним - неинтересно всё, что связанно с ASP.Net & MSSQL SERVER.

Везет. Вот бросить бы все и махнуть в задрючинск (с) :-D

С опозданием, но может будет полезно.
0. Есть такая замечательная книжица Inside Microsoft® SQL Server® 2008: T-SQL Programming, в ней подробно изложено, как обрабатываются запросы.
1. При обработке запроса сначала идут кроссы, потом джойны, потом добавление значений для OUTER джойнов.
2. Порядок джойнов определяется порядком ON
3. Смотрим на твои ONы, в ссответствии со скобками:

FROM
(
    (
        Materiaal_T INNER JOIN
        (
            Leveranciers_T INNER JOIN
            (
                Handvat_T INNER JOIN
                (
                    OPDRUKBONS_T LEFT JOIN Klantenadressen_T ON OPDRUKBONS_T.Klantnummer=Klantenadressen_T.KlantNr   -- 1
                )
                ON Handvat_T.IDnr=OPDRUKBONS_T.Handvat -- 2
            )
            ON Leveranciers_T.IDnr=OPDRUKBONS_T.Leverancier  -- 3
        )
        ON Materiaal_T.IDnr=OPDRUKBONS_T.Materiaal -- 4
    )
    LEFT JOIN KLACHTEN_T ON OPDRUKBONS_T.KooporderNr=KLACHTEN_T.KooporderNr -- 4
)

4. Получаем:

FROM OPDRUKBONS_T
LEFT JOIN Klantenadressen_T ON OPDRUKBONS_T.Klantnummer = Klantenadressen_T.KlantNr
INNER JOIN Handvat_T ON OPDRUKBONS_T.Handvat = Handvat_T.IDnr
INNER JOIN Leveranciers_T OPDRUKBONS_T.Leverancier = Leveranciers_T.IDnr
INNER JOIN Materiaal_T ON OPDRUKBONS_T.Materiaal = Materiaal_T.IDnr
LEFT JOIN KLACHTEN_T ON OPDRUKBONS_T.KooporderNr = KLACHTEN_T.KooporderNr

5. Но, как правильно заметил дигитальный, порядок иннеров вообще не важен, а при левом джойне берутся все записи из левой таблицы и затем идет добавка нулей для несуществующих правых значений. То бишь в нашем случае порядок левых тоже неважен. И поэтому написав FROM OPDRUKBONS_T мы можем остальные 5 джойнов записывать в абсолютно любом порядке.
6. За скобки я в детстве убивал из рогатки.

НП.
В СКЛную тему.
Сегодня споткнулся об задачку.
ДАНО:
Мелкософтовский сиквел, 2005 или 2008...
Дурная самоджойнутая таблица-дерево.
Требуется сделать выборку двух уровней дерева.
Результат упорядочить по значению в поле, но в пределах подветви...
Делаю по простому - селект из юниона - все по букварю...
SELECT * FROM
(
SELECT S1.*, 1 as FLAG FROM TBL S1 WHERE <условия головной части>
UNION
SELECT S2.*, 2 as FLAG FROM TBL S2 WHERE <условия субветвей>
)
ORDER BY FLAG, <поле>
И это... пипец... не работает... при том, что по частям все работает...
Ругается на ошибку в районе ORDER BY...
Наверное надо будет скастить FLAG к чему-нибудь... или добавить
алиас к выборке...

он на внешний селект ругается. Зачем он, кстати?

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

алиас нужен, да. А просто select ... union select ... order by разве не то же самое?

не то же самое?
------
Неа... там сквозная нумерация по <поле> и надо грантировать заданный порядок - упорядоченая голова, упорядоченные хвосты...

Пофиксил:
... ) AS T
ORDER BY T.FLAG, T.<поле>
Глюкало...
Правда думаю, что к задачке придется возвращаться - там еще хвосты группировать надо-ть...

Еще в тему...
Меня сейчас обрадовали...
После почти месяца разработки... и попутного ЗАПРЕТА заниматься скриптами для миграции... на завтра надо иметь миграционную процедуру... структура & данные...
Кто бы знал как мне хочется кого-нибудь прибить...

Задачка к теме. Это действительно так, или я чего то не знаю..
Есть скрипт с саб-запросами. Показался громоздко, переделал под INNER JOIN.
Как я знаю, под-запросы выполняються медленее. Но в этом случае все наоборот.
-- 0.7 сек.
SELECT Id, Name, Workability,
(SELECT Id, Name, Workability,
(SELECT Id, Name, Workability
FROM ProductItem item
WHERE (sub.Id = item.SubCategoriesId))
FROM SubCategories sub

WHERE (sub.CategoriesId = cat.Id))
FROM Categories cat
-----------------------------
-- 4 сек. иссец..
SELECT cat.Id, cat.Name,cat.Workability,
sub.Id, sub.Name, sub.Workability,
item.Id, item.Name, item.Workability

FROM Categories cat
JOIN SubCategories sub on cat.Id = sub.CategoriesId
JOIN ProductItem item on sub.Id = item.SubCategoriesId
Есть какие-нить предположения?

Есть какие-нить предположения?
------
У меня просто ошибки в запросе.
- Сервер?
- Версия?
- Количество данных?

да, работаю с XML. Полный скрипт:
-------------------------------------------
SELECT Id, Name, Workability,
(SELECT Id, Name, Workability,
(SELECT Id, Name, Workability
FROM ProductItem item
WHERE (sub.Id = item.SubCategoriesId) FOR XML AUTO, TYPE)
FROM SubCategories sub
WHERE (sub.CategoriesId = cat.Id)FOR XML AUTO, TYPE)
FROM Categories cat
FOR XML AUTO, ROOT('block')
-------------------------------------------
MS SQL 2008
10.0.1600.22 ((SQL_PreRelease).080709-1414
4000 rows

Увы, с FOR XML разобраться все руки не доходят...
Что могу сказать - там скорее всего проблема в конвертации в XML... и последующей осечкой лишнего в текстовом варианте...
Первый вариант этого не должен делать - там принудительный мультискан с последовательным дампом...
Попробуй сделать построение отношения в виде подзапроса и уже из него сделать дамп в XML. Может получится...