На самом деле мне не нужно было много думать о правильном объединении, но я полагаю, что у меня не было почти 20 лет на написание SQL-запросов, чтобы найти разумное оправдание для их использования. Я наверняка видел их много, я полагаю, это связано с тем, что разработчики использовали встроенные построители запросов.
Всякий раз, когда я сталкивался с ним, я переписывал запрос, чтобы устранить его - я обнаружил, что им просто требуется слишком много дополнительной умственной энергии, чтобы учиться или переучиваться, если вы не посещали запрос в течение некоторого времени и Нередко намерение запроса терялось или возвращало неверные результаты - и обычно именно эта неправильность приводила к тому, что я просил выяснить, почему запросы не работали.
Размышляя об этом, после того, как вы введете правое соединение, у вас теперь есть то, что я бы посчитал конкурирующими ветвями логики, которые нужно встретить посередине. Если будут введены дополнительные требования / условия, обе эти ветви могут быть дополнительно расширены, и теперь вам придется усложнять работу, чтобы убедиться, что одна ветвь не приводит к неверным результатам.
Кроме того, как только вы введете правильное объединение, другие менее опытные разработчики, работающие над запросом позже, могут просто подключить дополнительные таблицы к части запроса с правым объединением и при этом расширить конкурирующие логические потоки, которые все еще нуждаются встретиться посередине; или в некоторых случаях, которые я видел, начинайте вложение представлений, потому что они не хотят касаться исходной логики, возможно, частично, потому что они могут не понимать запрос или бизнес-правила, которые действовали, которые управляли логикой.