Для простоти припустимо, що всі відповідні поля є NOT NULL.

Ви можете зробити:

SELECT
    table1.this, table2.that, table2.somethingelse
FROM
    table1, table2
WHERE
    table1.foreignkey = table2.primarykey
    AND (some other conditions)

Інакше:

SELECT
    table1.this, table2.that, table2.somethingelse
FROM
    table1 INNER JOIN table2
    ON table1.foreignkey = table2.primarykey
WHERE
    (some other conditions)

Чи працюють ці двоє однаково MySQL?

INNER JOIN - синтаксис ANSI, який слід використовувати.

Зазвичай це вважається більш читабельним, особливо коли ви приєднуєтесь до багатьох таблиць.

Його також можна легко замінити, OUTER JOINколи виникає потреба.

WHEREСинтаксис орієнтований більше реляційна модель.

Результат двох таблиць JOINed - це декартовий добуток таблиць, до яких застосований фільтр, який вибирає лише ті рядки, що поєднують стовпці, що відповідають.

Це простіше бачити за допомогою WHEREсинтаксису.

Що стосується вашого прикладу, то в MySQL (і в цілому в SQL) ці два запити є синонімами.

Також зауважте, що у MySQL також є STRAIGHT_JOINпункт.

За допомогою цього пункту ви можете контролювати JOINпорядок: яка таблиця сканується у зовнішньому циклі, а яка - у внутрішній.

Ви не можете керувати цим в MySQL за допомогою WHEREсинтаксису.

Інші зазначають, що INNER JOINдопомагає читанню людини, і це головний пріоритет, я згоден.
Дозвольте спробувати пояснити, чому синтаксис приєднання є більш читабельним.

Основний SELECTзапит:

SELECT stuff
FROM tables
WHERE conditions

SELECTСтаття говорить нам , що ми отримуємо назад; FROMпункт говорить нам , де ми отримуємо його від, і WHEREпункт говорить нам , які з них ми отримуємо.

JOIN - це твердження про таблиці, про те, як вони пов'язані між собою (концептуально, власне, в одну таблицю).

Будь-які елементи запиту, які керують таблицями - звідки ми отримуємо речі - семантично належать до FROMпункту (і, звичайно, саме там JOINідуть елементи). Якщо ввести елементи приєднання до WHEREпункту, суперечить, що і звідки , тому JOINсинтаксис є кращим.

Застосування умовних висловлювань у ON / WHERE

Тут я пояснив етапи обробки логічних запитів.

Довідка: Всередині Microsoft® SQL Server ™ 2005 Запит на T-SQL
Видавець: Microsoft Press
Pub Дата: 07 березня 2006 р.
Друк ISBN-10: 0-7356-2313-9
Друк ISBN-13: 978-0-7356-2313-2
Сторінки: 640

Всередині Microsoft® SQL Server ™ 2005 T-SQL Querying

(8)  SELECT (9) DISTINCT (11) TOP <top_specification> <select_list>
(1)  FROM <left_table>
(3)       <join_type> JOIN <right_table>
(2)       ON <join_condition>
(4)  WHERE <where_condition>
(5)  GROUP BY <group_by_list>
(6)  WITH {CUBE | ROLLUP}
(7)  HAVING <having_condition>
(10) ORDER BY <order_by_list>

Перший помітний аспект SQL, який відрізняється від інших мов програмування, - це порядок обробки коду. У більшості мов програмування код обробляється в тому порядку, в якому він написаний. У SQL перше, що обробляється, є пропозицією FROM, тоді як пункт SELECT, який з’являється першим, обробляється майже останнім.

Кожен крок генерує віртуальну таблицю, яка використовується як вхід до наступного кроку. Ці віртуальні таблиці недоступні абоненту (клієнтська програма або зовнішній запит). Лише таблиця, що генерується на останньому кроці, повертається абоненту. Якщо певний пункт не вказаний у запиті, відповідний крок просто пропускається.

Короткий опис етапів обробки логічного запиту

Не переживайте занадто сильно, якщо опис кроків наразі не має особливого сенсу. Вони надаються в якості довідки. Розділи, що з’являються після прикладу сценарію, будуть висвітлювати кроки набагато детальніше.

1. ВІД: Декартовий продукт (перехресне з'єднання) виконується між першими двома таблицями пункту FROM, і в результаті створюється віртуальна таблиця VT1.

2. ON: фільтр ON застосовується до VT1. У <join_condition>VT2 вставляються лише рядки, для яких значення TRUE.

3. ВНУТРІШНЕ (приєднання): Якщо вказано ВІДНІШНЕ ПРИЄДНАННЯ (на відміну від CROSS JOIN або ВНУТРІШНЕ ПРИЄДНАННЯ), рядки із збереженої таблиці або таблиць, для яких не знайдено збігу, додаються до рядків VT2 як зовнішні рядки, генеруючи VT3 Якщо в пункті FROM з’являється більше двох таблиць, кроки 1 - 3 застосовуються повторно між результатом останнього з'єднання та наступною таблицею в пункті FROM, поки всі таблиці не будуть оброблені.

4. ДЕ: Фільтр WHERE застосовується до VT3. У <where_condition>VT4 вставляються лише рядки, для яких значення TRUE.

5. GROUP BY: Рядки з VT4 розташовані в групи на основі списку стовпців, зазначеного в пункті GROUP BY. VT5 генерується.

6. КУБА | ROLLUP: Супергрупи (групи груп) додаються до рядків з VT5, генеруючи VT6.

7. ВИДАЛЕННЯ: Фільтр HAVING застосовується до VT6. У <having_condition>VT7 вставляються лише групи, для яких значення TRUE.

8. SELECT: Список SELECT обробляється, генеруючи VT8.

9. DISTINCT: Дублікати рядків видаляються з VT8. VT9 генерується.

10. ЗАМОВИТИ ЗА: Рядки з VT9 сортуються відповідно до списку стовпців, зазначеного у пункті ЗАМОВЛЕННЯ ПО. Створюється курсор (VC10).

11. ВЕРХ: Вказане число або відсоток рядків вибирається з початку VC10. Таблиця VT11 генерується та повертається абоненту.

(Застосування умовних операторів у програмі ON / WHERE не матиме великої різниці в кількох випадках. Це залежить від того, скільки таблиць ви приєднали та кількість рядків, доступних у кожних таблицях приєднання)

Синтаксис ANSI з приєднанням старіший, менш очевидний і не рекомендується.

Крім того, реляційна алгебра дозволяє взаємозамінювати предикати в WHEREпункті та INNER JOIN, тому навіть INNER JOINзапити з WHEREпропозиціями можуть мати предикати, переставлені оптимізатором.

Рекомендую писати запити максимально читаним способом.

Іноді це включає створення INNER JOINвідносно "неповних" та внесення деяких критеріїв WHEREпросто для того, щоб зробити списки критеріїв фільтрації більш легкими у здійсненні.

Наприклад, замість:

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
    AND c.State = 'NY'
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
    AND a.Status = 1

Написати:

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
WHERE c.State = 'NY'
    AND a.Status = 1

Але це, звичайно, залежить.

Неявне приєднання (яке називається вашим першим запитом) стає набагато більш заплутаним, важким для читання та важким обслуговуванням, коли вам потрібно почати додавати більше запитів до запиту. Уявіть, що ви робите той самий запит і тип з'єднання на чотирьох-п'яти різних таблицях ... це кошмар.

Використання явного з'єднання (ваш другий приклад) набагато легше читати і легко обслуговувати.

Я також зазначу, що використання старшого синтаксису більше піддається помилкам. Якщо ви використовуєте внутрішнє з'єднання без пункту ON, ви отримаєте синтаксичну помилку. Якщо ви використовуєте старіший синтаксис і забудете одне з умов приєднання в пункті де, ви отримаєте перехресне з'єднання. Розробники часто виправляють це, додаючи чітке ключове слово (замість того, щоб виправляти з'єднання, оскільки вони все ще не розуміють, що з'єднання порушено), що, можливо, виправить проблему, але значно сповільнить запит.

Крім того, для технічного обслуговування, якщо ви маєте перехресне з'єднання у старому синтаксисі, як утримувач буде знати, якщо ви мали намір мати його (є ситуації, коли потрібні перехресні з'єднання) або якщо це була аварія, яку слід виправити?

Дозвольте вказати на це запитання, щоб зрозуміти, чому неявний синтаксис поганий, якщо ви використовуєте ліві приєднання. Sybase * = до Ansi Standard з двома різними зовнішніми таблицями для тієї ж внутрішньої таблиці

Плюс до цього (персональний рент тут), стандарт, який використовує явні приєднання, старший за 20 років, а це означає, що синтаксис неявного приєднання застарів на ці 20 років. Ви б написали код програми за допомогою синтаксису, який застарів уже 20 років? Чому ви хочете написати такий код бази даних?

Вони мають інше, читабельне для людини значення.

Однак, залежно від оптимізатора запитів, вони можуть мати однакове значення для машини.

Ви завжди повинні код читати.

Тобто, якщо це вбудовані відносини, використовуйте явне з'єднання. якщо ви збігаєтеся на слабко пов'язаних даних, використовуйте пункт де.

Стандарт SQL: 2003 змінив деякі правила пріоритетності, тому оператор JOIN має перевагу над об'єднанням "кома". Це фактично може змінити результати вашого запиту залежно від способу налаштування. Це спричиняє деякі проблеми для деяких людей, коли MySQL 5.0.12 перейшов на дотримання стандарту.

Отже, у вашому прикладі ваші запити працювали б однаково. Але якщо ви додали третю таблицю: ВИБІРТЕ ... З таблиці1, таблиця2 ПРИЄДНАЙТЕ у таблицю3 НА… ДЕ…

До MySQL 5.0.12 спочатку будуть приєднані table1 та table2, а потім table3. Тепер (5.0.12 і далі) спочатку приєднуються таблиця2 та таблиця3, потім таблиця1. Це не завжди змінює результати, але це може, і ви можете навіть не усвідомлювати цього.

Я ніколи більше не використовую синтаксис "кома", вибираючи ваш другий приклад. Так чи інакше, це зручніше для читання, умови ПРИЄДНАННЯ - з JOIN, а не розділені в окремий розділ запитів.

Я знаю, що ви говорите про MySQL, але все одно: в Oracle 9 явні приєднання та неявні приєднання створюють різні плани виконання. AFAIK, який вирішено в Oracle 10+: такої різниці вже немає.

Синтаксис приєднання ANSI, безумовно, більш портативний.

Я переглядаю оновлення Microsoft SQL Server, і я також зазначу, що синтаксис = * і * = для зовнішніх з'єднань у SQL Server не підтримується (без режиму сумісності) для сервера 2005 sql та пізніших версій.

Якщо ви часто програмуєте динамічні збережені процедури, ви полюбите свій другий приклад (використовуючи де). Якщо у вас є різні вхідні параметри і багато мордочки, то це єдиний спосіб. В іншому випадку вони обидва будуть виконувати один і той же план запитів, тому однозначно різниці в класичних запитах точно немає.