Старый плюшевый мишкаВ современных условиях наверное действительно лучше стремиться к канонической форме хотя бы для читабельности
даже если "каноническая" форма приводит к взбрыкиванию оптимизатора, любые подобные отклонения надо рассматривать именно как отклонения. И если уж и использовать, то с обязательной пометкой такого запроса как "криво оптимизируемого".
Или вообще его переписать так, чтобы вопросов к оптимизатору не было (если возможно).
Приведу пример.

Известно, что при plan sort строится временный файл, который состоит из фиксированных записей макс. длины равной ключ (order by) плюс содержимое select <column_list>.
Если в этом <column_list> какой-нибудь varchar(10000), ясное дело, файл сортировки получится конского размера.

Например



в этом запросе вот этот здоровенный столбец - Table1.REF_REMPLACEMENT.

Еманов (или кто еще) придумал такой трюк. Берем, получаем отсортированный набор идентификаторов, а потом по нему выбираем этот столбец, джойном.



Все вроде прекрасно - сначала сортируется внутренний подзапрос, а потом к нему приклеивается джойном внешняя часть.
И это работает. Однако.
Когда я стал проверять это же самое в InterBase 2017, обнаружилось, что в ИБ результат нихрена не сортированный, и его приходится сортировать еще раз.
Так вот, выяснилось, что оптимизатор ФБ берет вот этот сорт-файл за базу, и к нему пристегивает джойн, а оптимизатор ИБ делает это НЕ ТАК.
И в этот момент я понял, что оптимизатор ФБ как раз-то и не прав. В том смысле неправ, что нельзя ориентироваться на результат сортировки внутреннего подзапроса. И если хочешь отсортировать РЕЗУЛЬТАТ, то order by должно быть в конце всего, а не где-то в середине.
А это (order by в конце) убивает весь этот придуманный трюк.

Ну это как Еманов регулярно говорит - "не надейтесь на group by, что он вам правильно отсортирует. В будущих версиях group by может использовать другой метод доступа, который будет выдавать записи в другом порядке". И теперь вдруг тот же Еманов говорит - "используйте вот такой трюк, оно вам отсортирует".
Собственно, я тут Еманова никак не обвиняю, я просто говорю, что не надо реляционную алгебру подстраивать под особенности оптимизатора. Думать надо именно реляционной алгеброй. Разумеется, с учетом специфики нашего оптимизатора. Но именно реляционная алгебра даст правильное понимание join, on, where и прочего. А оптимизатор меняется с каждым релизом. И если начать думать "за оптимизатор", а не реляционной алгеброй, то у вас через 3-4 версии просто поедет крыша :-)

Старый плюшевый мишкаКак мне говорил владелец бизнеса - мы тут не программы красивые пишем, мы тут бумагой торгуем.
не, так не пойдет. :-) Если вернуться к исходному вопросу этого топика, то речь не о красивой программе, а о том, каким должен быть мыслительный процесс для решения задачи. А если правильного процесса нет (раз нет понимания кубиков, из которых решение складывается), то и решения нет, или оно неправильное. А красивое и правильное - это не одно и то же.

p.s. меня регулярно пробивает на "помню, что тут было вот так, поэтому...". Но чтобы "оптимизатор при помещении в on условия where как-то иначе оптимизировал" - если такое даже и было (а я такого не помню), то оно уехало далеко и надолго.
Интересующиеся, кстати, на мои примеры должны были сразу тут привести куски explain plan в ФБ 3. Видимо, никого не торкнуло.
Ну хоть кто на семинаре последнем был в Москве, вы-то попробуйте.

Гаджимурадов Рустам,

я в эпистолярном только в детстве писал. А "Трое в серверной" - Ковязина.