Почему использование пункт СОЕДИНЕНИЯ по сравнению с, ГДЕ условие?

Мне не нравится этот стиль, потому что он затрудняет определение того, какие предложения WHERE предназначены для имитации JOIN , а какие - для реальных фильтров. , и мне не нравится код, который излишне затрудняет определение первоначального намерения программиста.

Самая большая проблема, с которой я столкнулся с этим форматом - это тенденция забывать предложение WHERE некоторого соединения, в результате чего получается декартово произведение. Это особенно часто (для меня по крайней мере) при добавлении новой таблицы в запрос. Например, предположим, что таблица ADDRESSES добавлена ​​в смесь, и вы немного забыли:

SELECT *
  FROM customers c, invoices i, addresses a
 WHERE c.customer_id = i.customer_id
   AND i.amount > 999.99
 ORDER BY i.amount, c.name

Бум! Декартово произведение! :)

Соединение в старом стиле в некоторых случаях совершенно неверно ( внешние соединения являются виновником). Хотя они более или менее эквивалентны при использовании внутренних объединений, они могут генерировать неверные результаты с внешними объединениями, особенно если столбцы на внешней стороне могут иметь значение NULL. Это связано с тем, что при использовании старого синтаксиса условия соединения не логически вычисляются до тех пор, пока не будет построен весь набор результатов, просто невозможно выразить условие для столбца с внешней стороны соединения, которое будет фильтровать записи, когда столбец может иметь значение NULL, потому что нет соответствующей записи.

В качестве примера:

Выберите всех клиентов и сумму продаж виджетов по всем их счетам в августе, когда счет был обработан (Invoice.ProcessDate равен Not Null)

с использованием нового синтаксиса соединения ANSI-92

 Select c.name, Sum(d.Amount)
 From customer c
    Left Join Invoice I 
        On i.custId = c.custId
            And i.SalesDate Between '8/1/2009' 
                      and '8/31/2009 23:59:59'
            And i.ProcessDate Is Not Null
    Left Join InvoiceDetails d 
        On d.InvoiceId = i.InvoiceId
            And d.Product = 'widget'
 Group By c.Name

Попробуйте сделать это со старым синтаксисом ... Поскольку при использовании синтаксиса старого стиля все условия в предложении where оцениваются / применяются ПЕРЕД «внешние» строки добавляются обратно, все строки необработанных счетов будут добавлены обратно в окончательный набор результатов ... Таким образом, это невозможно со старым синтаксисом - все, что пытается отфильтровать счета с нулевыми обработанными датами, будет устранено клиенты ... единственная альтернатива - использовать коррелированный подзапрос.

С тех пор я узнал, что это не стандартный синтаксис SQL.

Это не совсем так. Синтаксис «a, b where» взят из стандарта ansi-89, синтаксис «a join b on» - ansi-92. Однако синтаксис 89 является устаревшим , что означает, что вы должны не использовать его для новых запросов.

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

Проблемой при выборе условия соединения может быть предложение where. Для чего-либо, кроме одного, старый стиль - абсолютное зло. И когда вы узнаете новый стиль, вы можете просто продолжать его использовать.

Это стандартный синтаксис SQL, просто более старый стандарт, чем JOIN. Есть причина, по которой синтаксис эволюционировал, и вы должны использовать новый синтаксис JOIN, потому что:

1. Он более выразительный, четко указывает, какие таблицы объединены, порядок JOIN, какие условия применяются к какому JOIN, и отделяет условия фильтрации WHERE из условий JOIN.

2. Он поддерживает LEFT, RIGHT и FULL OUTER JOIN, чего нет в синтаксисе WHERE.

Я не думаю, что вы найдете JOIN типа WHERE существенно менее переносимым, чем синтаксис JOIN .

Пока вы не используете функцию естественного соединения ANSI, меня это устраивает.

Я нашел эту цитату - СкоттЧер, я полностью согласен:

Я нахожу синтаксис WHERE легче читать, чем INNER JOIN - я думаю, это похоже на Vegemite. Большинство людей в мире, вероятно, находят его отвратительным, но дети, выросшие на его еде, обожают его.

Это действительно зависит от привычек, но я всегда находил синтаксис Oracle, разделенный запятыми, более естественным. Первая причина заключается в том, что я думаю, что использование (INNER) JOIN снижает удобочитаемость. Второй - о гибкости. В конце концов, соединение по определению является декартовым произведением. Необязательно ограничивать результаты на основе идентификаторов обеих таблиц. Декартово произведение двух таблиц может потребоваться, хотя и очень редко. Ограничение их на основе идентификаторов - вполне разумная практика, но НЕ ПРАВИЛО . Однако, если вы используете ключевое слово JOIN , например, в SQL Server, оно не позволит вам опустить ключевое слово ON . Предположим, вы хотите создать комбинированный список. Вы должны сделать это так:

SELECT *
FROM numbers
JOIN letters
ON 1=1

Кроме того, Я считаю, что синтаксис Oracle (+) также очень разумен. Это хороший способ сказать: « Добавьте и эту запись в набор результатов, даже если она пуста. « Это намного лучше, чем синтаксис RIGHT / LEFT JOIN , потому что в по факту нет ни левого, ни правого! Когда вы хотите объединить 10 таблиц с несколькими разными типами внешних объединений, возникает путаница, какая таблица находится «слева», а какая справа.

Кстати, в качестве более общего комментария, я не Я не думаю, что переносимость SQL больше существует в практическом мире. Стандартный SQL настолько плох, а выразительность разнообразного синтаксиса СУБД так часто востребована, что я не думаю, что 100% переносимый код SQL - достижимая цель. Наиболее очевидным свидетельством моих наблюдений является старый добрый номер строки проблематичный. Просто выполните поиск на любом форуме по запросу " sql row number" , включая SO, и вы увидите сотни сообщений, спрашивающих, как этого можно добиться в конкретной СУБД. Сходным и связанным с этим является ограничение количества возвращаемых строк , например ..

Итак ... став счастливым обладателем значка перекати-поле, я вернулся к этому, чтобы попытаться найти способ обойти это. ; -)

Я не уверен, что мне нравится это решение, поэтому я все еще очень открыт для любых лучших подходов.

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

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

На самом деле этот синтаксис более переносим, ​​чем JOIN, потому что он будет работать практически с любой базой данных, в то время как не все поддерживают синтаксис JOIN (Oracle Lite не поддерживает , например [если это недавно не изменилось]).