Соединения SQL: будущее стандарта SQL ANSI (где и соединение)?

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

Но есть много причин использовать новый синтаксис соединения. Среди прочего:

• Читабельность
• Ремонтопригодность
• Более легкий переход на внешние соединения

Вместо того, чтобы беспокоиться о каком-то возможном риске в будущем, почему бы не беспокоиться о риске, с которым вы сталкиваетесь прямо сейчас?

В дополнение к пунктам Марка:

• Код труднее читать (и, следовательно, понимать его назначение), когда предложения ON отсоединены (иногда на много строк) от соединяемых таблиц. Это увеличивает вероятность ошибок при модификации кода.
• Определить, какой тип JOIN выполняется, сложнее — вам нужно просмотреть предложение WHERE и надеяться, что то, что вы видите, верно.
• Найти отсутствующие предложения JOIN намного сложнее, что увеличивает риск непреднамеренного декартова соединения — при использовании синтаксиса ANSI предложения ON хорошо выстраиваются, что делает эту задачу тривиальной.

Есть много причин избегать неявных соединений. Большие из них:

• Его нельзя легко изменить на внешнее соединение.
• С неявным соединением проще забыть условие соединения.
• Если вы смешиваете как неявные, так и явные соединения, вы получаете проблемы с запутанным приоритетом. Вот пример, сделанный несколько часов назад: Синтаксическая ошибка MySQL.

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

Оба синтаксиса поддерживаются последними версиями ISO SQL (2003, 2008). Использование запятых для указания перекрестного соединения в предложении FROM является совершенно стандартным SQL и поддерживается всеми продуктами SQL, с которыми я сталкивался. Кажется крайне маловероятным, что он когда-либо будет или даже может быть объявлен устаревшим или прекращенным в SQL.

Пока они не используют ***= и =* для своего синтаксиса соединения (который был устарел в SQL Server 2008 R2), я не думаю, что он исчезнет в долгосрочной перспективе, но, как говорит Марк Байерс, есть много причин не делать этого.

Больше всего меня беспокоит то, что если они пишут такие соединения, что еще они делают нестандартного?

У людей было несколько хороших моментов, но пока есть два важных, которые не были упомянуты:

1. Независимо от того, давали ли внешние соединения *= и =* в старом стиле правильные результаты, они также не могут правильно обозначать определенные соединения. Рассмотрим следующий запрос. Мы хотим показать всем клиентам, которые не разместили заказ на сумму более 100 долларов США:

   SELECT
   FROM
      Customer C
      LEFT JOIN Order O ON C.OrderID = O.OrderID AND O.OrderTotal >= 100.0;
   WHERE
      O.OrderID IS NULL;
   

   Попробуйте выразить это по-старому... если сможете. Без использования производных таблиц.

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

   SELECT
      C.FullName,
      C.CustomerCode,
      O.OrderDate,
      O.OrderTotal,
      OD.ExtendedShippingNotes
   FROM
      Customer C
      INNER JOIN Order O ON C.CustomerID = O.CustomerID
      INNER JOIN OrderDetail OD ON O.OrderID = OD.OrderID
   WHERE
      C.CustomerStatus = 'Preferred'
      AND O.OrderTotal > 1000.0;
   

   Это разделение означает, что разработчику, просматривающему запрос, не приходится иметь дело с кучей беспорядка при поиске отличительных особенностей этого запроса. Если он знаком с таблицами, он может полностью пропустить предложение FROM и просто прочитать предложение WHERE, чтобы получить всю необходимую ему информацию. Это быстрее. И если вам наплевать на скорость, даже при простом сканировании запросов глазами, я не хочу с вами работать.

   Теперь для тех, кто думает, что есть что-то особенное в расположении всего при использовании синтаксиса JOIN, вы ошибаетесь. Следующий запрос работает так же хорошо, как и предыдущий:

   SELECT
      C.FullName,
      C.CustomerCode,
      O.OrderDate,
      O.OrderTotal,
      OD.ExtendedShippingNotes
   FROM
      Customer C
      CROSS JOIN Order O
      INNER JOIN OrderDetail OD
         ON C.CustomerID = O.CustomerID
         AND C.CustomerStatus = 'Preferred'
         AND O.OrderTotal > 1000.0
   WHERE
      O.OrderID = OD.OrderID;
   

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

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

Трудно спорить об изяществе или безобразии той или иной синтаксической конструкции. Вы просто видите это или нет. Синтаксис соединения, разделенного запятыми, отражает фундаментальную особенность реляционной алгебры, которая утверждает нормальную форму для запросов выбора-проекта-соединения. Единственный тип соединения, который его избегает (и, следовательно, требует специального синтаксиса), — это внешнее соединение. Случайные ошибки отсутствия предикатов равенства, из-за которых граф соединения становится непересекающимся, — это всего лишь вопрос сложности вашего внешнего инструмента программирования SQL (отображает ли он граф соединения вообще?).

Это не только эстетика. В рабочих базах данных обычно есть такие столбцы, как CREATED_ON или COMMENTS, во многих таблицах. В этом случае синтаксис NATURAL JOIN просто опасен.

Как красноречиво выразился Энтони Молинаро (автор популярной «Поваренной книги SQL»): «Старый стиль краток, мил и совершенен. ANSI упростил его, и для людей, которые какое-то время занимались разработкой, это совершенно не нужно".

Подразумеваемый синтаксис правого и левого соединения *= и =* устарел и по уважительной причине в настоящее время не всегда возвращает правильные результаты. Если они использовали это, они ДОЛЖНЫ быть исправлены сейчас, поскольку в настоящее время они подвергают вас риску получения неверных результатов. Это не вариант. Другой синтаксис будет продолжать работать, но его также следует заменить по нескольким причинам. Во-первых, очень легко получить случайные перекрестные соединения, которые могут возвращать плохие результаты или которые исправляются с помощью различных, что может создать проблемы с производительностью.

Другой вопрос - техническое обслуживание. Если позже люди добавят в запрос другие соединения и снова начнут смешивать подразумеваемые и явные соединения, вы можете получить неправильные результаты и даже не знать об этом. ОЧЕНЬ ОЧЕНЬ плохо оставлять такой дрянной код в своей кодовой базе. Подразумеваемые соединения также труднее понять, и, поскольку они часто пишутся разработчиками, которые ничего не понимают в соединениях, они в любом случае могут оказаться не тем, что вам нужно. И если в запросе есть перекрестное соединение, как сопровождающему узнать, было ли это ошибкой (и случайным перекрестным соединением) или преднамеренным перекрестным соединением (иногда они нам действительно нужны). Я бы не принял этот код в том виде, в котором он написан. Я бы настаивал на том, чтобы некомпетентные авторы исправили это без дополнительной оплаты.

Если вы беспокоитесь, что они будут удалены из Стандарта или из продуктов SQL, не волнуйтесь. Это вряд ли когда-либо произойдет.

Этот «старый стиль» соединения — это просто вопрос стиля. Те, кто одобряет его, клянутся, что есть ситуации, когда соединения «старого стиля» легче понять. Хотя я сам не совсем в этом уверен, одно можно сказать наверняка: соединения старого стиля будут время от времени встречаться, а реинжиниринг кода в соответствии с вашим личным стилем не всегда уместен. Поэтому привыкайте к стилю и учитесь с ним работать.