Рекомендации по порядку присоединяемых столбцов в sql-соединении?

ProgramBox

Рекомендации по порядку присоединяемых столбцов в sql-соединении?

Post author:admin
Запись опубликована:3 февраля, 2023
Post category:Вопросы по программированию

#sql

Вопрос:

В моем офисе идет большая дискуссия о порядке соединенных столбцов в sql-соединении. Мне сложно это объяснить, поэтому я просто представлю два оператора sql. Какой из них лучше с учетом рекомендаций sql?

 SELECT a.Au_id 
FROM   AUTHORS a 
       INNER JOIN TITLEAUTHOR ta 
         ON a.Au_id = ta.Au_id 
       INNER JOIN TITLES t 
         ON ta.Title_id = t.Title_id 
WHERE  t.Title LIKE ‘%Computer%’

или

 SELECT a.Au_id 
FROM   AUTHORS a 
       INNER JOIN TITLEAUTHOR ta 
         ON ta.Au_id = a.Au_id
       INNER JOIN TITLES t 
         ON t.Title_id = ta.Title_id
WHERE  t.Title LIKE ‘%Computer%’

Итак, в соединении, в части ON, имеет ли значение, пишете ли вы A.x = B.y or B.y = A.x ?

1. Я бы использовал тот же порядок, JOINs что и, поэтому версия 1. Просто потому, что она более удобочитаема. Кстати, в . Для NET LINQ (всех поставщиков) это даже обязательно.

2. Поскольку функциональной разницы нет, все сводится к делу вкуса. В этом смысле: я предпочитаю версию 2.

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

4. Это не имеет значения, поскольку SQL-Server оптимизирует его, но вы могли бы сделать это важным: добавить OPTION (FORCE ORDER) в запрос. Общее эмпирическое правило: порядок соединения должен быть с таблицей наименьшего количества записей сверху, а большинство записей последними. Порядок в ON предложении — это (очевидно) дело вкуса.

Ответ №1:

Лучшая практика здесь — выбрать один и придерживаться его в команде. Лично я предпочитаю FROM a JOIN b ON b.col = a.col , потому что мне это кажется более чистым.

1. Почему чище менять порядок?

2. ДА! В отсутствие наилучшей практики следующая лучшая практика — быть последовательной . Хотя я действительно не думаю, что это слишком важно в предложении ON.

3. @TimSchmelter Почему я не люблю пиво (к сожалению)? Просто дело вкуса

4. @ThomasRuiz: согласованность — это не вопрос вкуса и a join b on b = a не последовательный порядок, не так ли? Однако я согласен, что наиболее важно, чтобы вся команда использовала один и тот же способ.

5. @LievenCardoen, я думаю, что есть некоторые, связанные с конкретными администраторами баз данных. Google может быть лучшим ответом, который я могу вам дать 🙂 (и да, я перепробовал много разных сортов пива, думаю, мне просто не повезло)

Ответ №2:

SQL был разработан так, чтобы его можно было читать как обычный текст на английском языке. В обычном тексте, когда мы хотим указать какой-либо упомянутый объект, мы говорим что-то вроде «Объект. Этот объект похож на этот объект, этот объект связан с этим объектом, и этот объект обладает этими свойствами «. Мы не говорим: «Этот объект похож на этот объект, и этот объект связан с этим объектом, и эти свойства имеют этот объект».

Итак, когда мы добавляем записи TableB в запрос из TableA, нам нужно указать, что должна иметь запись из TableB, чтобы соответствовать текущей записи из TableA. Итак, мы должны сказать: «нам нужны записи из TableB, которые имеют идентификатор, равный TableA.ИДЕНТИФИКАТОР», т. Е. FROM TableA a JOIN TableB b ON b.col = a.col . Мы должны писать именно в этом порядке, чтобы обеспечить легкое чтение и понимание этого отношения.

И мне очень, очень грустно, что почти вся документация по SQL не содержит каких-либо аргументов для того, чтобы идти в том или ином направлении в этом вопросе, но есть много примеров неправильного написания аргументов уравнения в порядке представления таблиц в запросе.

1. С другой точки зрения, в английских текстах мы можем использовать определенные и неопределенные артикли, чтобы упомянуть то, что мы уже знаем, и то, что еще не знаем и хотим указать в предложении. Это позволяет не зависеть от порядка элементов в предложении. Таким образом, порядок не так критичен для носителей английского языка, как статьи. Например, в русском языке нет артиклей, и мы используем порядок в предложении или интонацию, чтобы отметить, что нового в предложении и что уже известно в контексте. Но в SQL у нас также нет статей!

Ответ №3:

Я всегда использовал вариант 1, и именно так orcale преподает его на своем курсе SQL и PL / SQL.

На предмет наилучшей практики, хотя,

Одна вещь, которую вы использовали, которой также учит oracle, — это псевдонимы таблиц из 1 или 2 букв.. Хотя в то время это может показаться отличной идеей, и это упрощает написание инструкции / процедуры / функции (в то время), может быть сложно вернуться и посмотреть на тот же фрагмент кода позже.

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

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

(Не совсем по теме объединений, а по теме наилучшей практики)

Ответ №4:

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

Способ, которым оптимизатор oracle обрабатывает объединения, объясняется довольно подробно на http://docs.oracle.com/cd/B10501_01/server.920/a96533/optimops.htm#39473 .

Ответ №5:

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

http://weblogs.sqlteam.com/joew/archive/2008/02/29/60542.aspx