Скоро пятница,

ответ - нет. идеологически более верно в on писать именно условие объединения, а в where - условия фильтрации получаемого результата.
см. http://www.ibase.ru/joins/
раздел "Отличие между On и Where" и дальше в разделе "Left/Right Join"

в качестве дополнительного примера можно привести запрос



мы не можем включить where o.id is null в on, потому что это не является условием объединения, и вообще записей с o.c_id is null в таблице orders не существует. Но эти записи возникают в результате работы left join.

В разделе "Left/right join" есть обратный пример, когда ошибочный вынос условия ON в where меняет результат запроса.

В общем, on и where - это не одно и то же. Если для inner join результат не отличается, то для left/right join - разница есть.

Скоро пятницаЧто за рекомендация, чья(откуда)?
вопрос странный. рекомендация обусловлена синтаксисом. Если вы пытаетесь схитрить, то обманете сами себя - например, привыкнете для inner join втыкать where в условие on, а потом напоретесь на то, что в left join получите "не тот" результат.
Ну или тот, кто будет читать ваши запросы, будет долго думать, какого хрена в on написано то, что должно быть в where.

WildSeryА о каком случае "напоретесь"
у меня в статье этот случай прописан. пример - дата по заказам в on и where. Но это опять же по правой части left join.

Для меня, собственно, этот вопрос не существует. ON это условие объединения двух таблиц. То есть столбец из таблицы А и столбец из таблицы Б.
WHERE - это условие фильтрации по столбцам одной из таблиц.
Да, в ON можно добавить условие по одному из столбцов чтобы ОГРАНИЧИТЬ записи, по которым делается join, в дополнение к объединению по "столбец из А и столбец из Б".

То есть, у меня в голове множества до join и после не являются одним и тем же, даже если бы результат их объединения и фильтрации был одинаковым. :-)

A join B on a.id = b.a_id and a.id > 10

это последовательно:
- ограничение множества A -> множество А штрих.
- объединение множества А штрих и множества Б

Сейчас это заменяется на
(select from A where a.id > 10) join B on a.id = b.a_id

здесь
A join B on a.id = b.a_id
where a.id > 10

последовательно
- объединение множеств А и Б - результат = множество С
- применение фильтра над множеством С

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

Гаджимурадов РустамРазумеется, если множеств (таблиц) больше двух, то и вариантов
их пересечений и результатов становится больше.
не-а. джойны все равно попарно выполняются (обрабатываются). в inner пары могут образовываться в зависимости от кардинальности (типа A + (B+C) или (A+B) +C и т.д.), а в left/right они образуются жестко в порядке следования.
Ну и еще, a right join b преобразуется оптимизатором в b left join a.

Так что, вариантов пересечения там больше не образуется, т.к. их последовательность по большей части фиксированная.

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

Известно, что при 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. Видимо, никого не торкнуло.
Ну хоть кто на семинаре последнем был в Москве, вы-то попробуйте.

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

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