Чи є істотна різниця між запитами, приєднаними до пунктів WHERE, та запитами, що використовують фактичний приєднання?

У Learn SQL The Hard Way (вправа шість) автор подає наступний запит:

SELECT pet.id, pet.name, pet.age, pet.dead
    FROM pet, person_pet, person
    WHERE
    pet.id = person_pet.pet_id AND
    person_pet.person_id = person.id AND
    person.first_name = "Zed";

і далі каже, що:

Насправді є й інші способи змусити такі запити працювати під назвою "приєднується". Я зараз уникаю цих концепцій, бо вони шалено заплутані. Просто дотримуйтесь цього способу приєднання таблиць зараз і ігноруйте людей, які намагаються сказати [ви], що це якось повільніше або "низький клас".

Це правда? Чому або чому ні?

З авторським підходом викладати ЗОВНІШНІ ПРИЄДНАННЯ буде набагато складніше. Пункт ON у програмі INNER JOIN ніколи не вражав мене, як і багато інших речей. Можливо, це тому, що я ніколи не навчився старого. Мені б хотілося подумати, що є причина, що ми її позбулися, і це не бути самовдоволеним і називати цей метод низьким класом.

Це правда у дуже вузькому сценарії, який автор створив:

• Такий вхідний рівень SQL, що використання ON, є складним
• Тільки з огляду на ПРИЄДНАЙТЕСЬ / ВНУТРІШНЕ ПРИЄДНАННЯ, а не на ВІДНІШНІ ПРИЄДНАННЯ
• Ізольований кодер, який не повинен читати чужий код, а також не має людей, які мають досвід читання / використання кодового режиму ON.
• Не вимагає складного запиту з великою кількістю: таблиць, якщо є, але є і або.

Я вважаю, що як частина прогресивної роботи у навчанні, простіше її зруйнувати та мати природний прогрес:

Select * from table
select this, something, that from table
select this from table where that = 'this'
select this from table join anothertable on this.id = that.thisid

Концепції приєднання та фільтрування таблиць насправді не однакові. Вивчення правильний синтаксис тепер матиме більше Перехідний , коли ви дізнаєтеся OUTER JOINS якщо автор не має наміру на навчання застарілі / застарілі речі , як: *= or =*.

Чи буде це повільніше, залежить від оптимізатора запитів та того, як він впорядковує запит (те, що ви пишете, насправді не те, що виконується). Однак велика проблема цієї цитати полягає в тому, що вона повністю ігнорує той факт, що існують різні типи з'єднань, які діють абсолютно по-різному. Наприклад, те, що говориться, теоретично відповідає дійсності inner joins, але це не відповідає дійсності для outer joins( left joinsі right joins).

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

Слід використовувати новіший синтаксис. Основним аргументом для цього є те, що ваш запит матиме:

• Виберіть критерії
• Приєднуйтесь до критеріїв
• Критерії фільтра

Використовуючи старий стиль, поєднуються критерії приєднання та фільтрування, що у більш складних випадках може призвести до плутанини.

Також декартовий продукт можна отримати, забувши критерії приєднання у пункті про фільтр:

 person_pet.person_id = person.id

використовуючи старіший синтаксис.

Використання нового синтаксису також визначає, як має відбуватися з'єднання, що важливо щодо того, чи хочете ви INNER, LEFT OUTER тощо, тому це більш чітко щодо синтаксису JOIN, який IMHO збільшує читабельність для незнайомих людей з таблицями приєднання.

Не повинно бути, аналізатор запитів повинен генерувати еквівалентне внутрішнє представлення для еквівалентних запитів незалежно від того, як вони написані. Автор просто використовує синтаксис pre-SQL-92, і саме тому він згадує, що його можна розглядати як "старомодний" або "низький клас". Всередині аналізатор та оптимізатор повинні генерувати один і той же план запитів.

Я вивчив SQL таким чином, включаючи *=синтаксис зовнішніх приєднань. Для мене це було дуже інтуїтивно, оскільки всі відносини мали рівноправний пріоритет і краще працювали над створенням запитів у вигляді серії запитань: Що ви хочете? Звідки ви їх хочете? Яких ти хочеш?

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

Принаймні, у MSSQL немає суттєвої різниці у виконанні запитів, якщо ви використовуєте те саме замовлення приєднання. Однак, існує одна чітка, величезна проблема щодо вивчення (та використання) SQL таким чином. Якщо ви забудете одне зі своїх стосунків, ви отримаєте несподівані перехресні продукти. Що в базі даних будь-якого нетривіального розміру є надмірно дорогим (і небезпечним для невідбірників!). Набагато складніше забути відношення при використанні joinсинтаксису стилів.

Слід враховувати два різні аспекти цього: Продуктивність та ремонтопридатність / читабельність .

Ремонтопридатність / читабельність

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

Що вам краще виглядає і читання?

select
    e.LoginID,
    DepartmentName = d.Name
from HumanResources.Employee e
inner join HumanResources.EmployeeDepartmentHistory edh
on e.BusinessEntityID = edh.BusinessEntityID
inner join HumanResources.Department d
on edh.DepartmentID = d.DepartmentID
where d.Name = 'Engineering';

Або ...

select
    e.LoginID,
    DepartmentName = d.Name
from HumanResources.Employee e, 
HumanResources.EmployeeDepartmentHistory edh,
HumanResources.Department d
where e.BusinessEntityID = edh.BusinessEntityID
and edh.DepartmentID = d.DepartmentID
and d.Name = 'Engineering';

Особисто для мене перший є досить читабельним. Ви бачите, що ми з’єднуємо таблиці з INNER JOIN, тобто означає, що ми тягнемо рядки, які відповідають наступному пункту приєднання (тобто "приєднати працівника до EmployeeDepartmentHistory на BusinessEntityID та включити ці рядки").

Останнє, кома для мене нічого не означає. Мене змушує замислитися, що ви робите з усіма цими WHEREпредикатами пункту.

Колишній читає більше так, як думає мій мозок. Я щодня переглядаю SQL і комами для приєднання. Що веде мене до мого наступного моменту ...

Насправді існують інші способи залучення таких запитів до роботи під назвою "приєднується"

Всі вони приєднуються. Навіть коми - це з'єднання. Те, що автор не називає їх, справді є їхнім падінням .... це не очевидно. Це повинно бути очевидним. Ви приєднання реляційних даних, будь то вказати вам JOINабо ,.

Продуктивність

Це, безумовно, буде залежати від RDBMS. Я можу говорити лише від імені Microsoft SQL Server. Це дуже рівнозначно. Звідки ти знаєш? Захопіть плани після виконання та подивіться, що саме робить SQL Server для кожного з цих операторів:

У наведеному вище зображенні я підкреслив, що я використовую обидва запити, як зазначено вище, і відрізняються лише явними символами для приєднання ( JOINvs ,). SQL Server робить те саме.

Підсумок

Не використовуйте коми. Використовуйте явні JOINтвердження.

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

Його приклад спонукає читача створити розумову карту її значення, яка має надзвичайно безлад.

SELECT pet.id, pet.name, pet.age, pet.dead
    FROM pet, person_pet, person
    WHERE
    pet.id = person_pet.pet_id AND
    person_pet.person_id = person.id AND
    person.first_name = "Zed";

Приблизно вище:

Отримайте ідентифікатор домашнього улюбленця, ім’я, вік і загибель для всіх домашніх тварин, person_pet та осіб, у яких ідентифікатор домашнього улюбленця збігається з pet_id person_pet, а person_id цього запису відбувається у відповідності з person_id людини, якій FIRST_NAME є "Zed"

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

Існує причина, чому приєднання є загальними, і це стара класична канарка "відокремлення проблем". Зокрема, для SQL-запиту є вагомі підстави відокремити, як структуруються дані щодо того, як фільтруються дані.

Якщо запит написано чистішим, наприклад

SELECT pet.id, pet.name, pet.age
FROM pet
  JOIN person_pet ON pet.id = person_pet.pet_id
  JOIN person ON person.id = person_pet.person_id
WHERE 
  person.first_name = "Zed";

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

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

Хлопець робить класичну помилку. Він намагається навчити абстрактне поняття із конкретною реалізацією. Як тільки ви це зробите, ви потрапляєте в подібний бардак.

Потрібно спочатку навчити базовим поняттям баз даних, а потім показати SQL як один із способів їх опису.

Ліві та праві з'єднуються, можна стверджувати, що вони не мають великого значення. Зовнішнє приєднання, ви можете використовувати старий *=і =*синтаксис.

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

Приклад еквівалентний простому переформулюванню з внутрішніми JOIN. Різниця полягає лише у додаткових можливостях, які дозволяє синтаксис JOIN. Наприклад, ви можете вказати порядок, в якому обробляються стовпці двох таблиць; див., наприклад, https://stackoverflow.com/a/1018825/259310 .

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

Коли я засвоїв SQL, форми INNER JOIN, LEFT JOIN тощо не існували. Як уже було сказано в інших відповідях, різні діалекти SQL мали кожен реалізований зовнішній приєднання, використовуючи ідіосинкратичний синтаксис. Це пошкодило портативність коду SQL. Зновлення мови разом вимагало певних змін, і ліве приєднання тощо було те, на чому вони вирішили.

Це правда, що для кожного INNER JOIN може бути записана еквівалентна кома з умовою приєднання в пункті WHERE. Мені знадобилося певний час, щоб перейти від подобається старої форми до переваги нової форми. Мабуть, автор Learning SQL The Hard Way все ще вважає, що старий спосіб простіше.

Чи є відмінності? Ну так, є. Перший полягає в тому, що INNER JOIN з пунктом ON розкриває наміри автора чіткіше, ніж старий стиль. Більш очевидним є той факт, що пункт ON є фактично умовою приєднання, а не якимсь іншим видом обмеження. Це робить код, який використовує INNER JOIN, легше засвоїти при читанні, ніж старий стиль. Це важливо при збереженні чужого коду.

Друга відмінність полягає в тому, що новий стиль полегшує оптимізатору запитів виявити виграшну стратегію. Це дуже малий ефект, але це реально.

Третя відмінність полягає в тому, що коли ви навчаєтесь, використовуючи INNER JOIN (або просто звичайний ПРИЄДНАЙТЕСЬ), це полегшує навчання LEFT JOIN тощо.

Крім цього взагалі немає матеріальної різниці.

Це залежить, якщо ви думаєте з точки зору множин та формальної логіки .....

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

Але якщо ви, як 99% людей, вам не сподобалася формальна логіка в ступені вашої математики, то ключове слово приєднання - це легше вивчити. SQL раніше був представлений в університеті як просто певний спосіб записувати формальні логічні запити ....