Dla uproszczenia załóżmy, że wszystkie odpowiednie pola są NOT NULL.

Możesz to zrobić:

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

Albo:

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

Czy te dwa działają w ten sam sposób MySQL?

INNER JOIN to składnia ANSI, której powinieneś użyć.

Jest to ogólnie uważane za bardziej czytelne, szczególnie gdy dołączasz do wielu tabel.

Można go również łatwo zastąpić, OUTER JOINgdy zajdzie taka potrzeba.

WHERESkładnia jest bardziej zorientowany model relacyjny.

Wynikiem dwóch tabel JOINed jest iloczyn kartezjański tabel, do których stosowany jest filtr, który wybiera tylko te wiersze z pasującymi łączącymi kolumnami.

Łatwiej to zauważyć dzięki WHEREskładni.

Na przykład w MySQL (i ogólnie w SQL) te dwa zapytania są synonimami.

Zauważ również, że MySQL ma również STRAIGHT_JOINklauzulę.

Za pomocą tej klauzuli można kontrolować JOINkolejność: która tabela jest skanowana w pętli zewnętrznej, a która w pętli wewnętrznej.

Nie można tego kontrolować w MySQL przy użyciu WHEREskładni.

Inni zauważyli, że INNER JOINpomaga to czytelności dla ludzi, i to jest najwyższy priorytet, zgadzam się.
Pozwól, że wyjaśnię, dlaczego składnia łączenia jest bardziej czytelna.

Podstawowe SELECTzapytanie jest następujące:

SELECT stuff
FROM tables
WHERE conditions

SELECTKlauzula mówi nam co wracamy; FROMklauzula mówi nam, gdzie jesteśmy coraz to od, a WHEREklauzula mówi nam , które z nich dostajemy.

JOIN jest stwierdzeniem o tabelach, w jaki sposób są one powiązane (koncepcyjnie, w rzeczywistości, w jedną tabelę).

Wszelkie elementy zapytania, które kontrolują tabele - skąd otrzymujemy rzeczy - semantycznie należą do FROMklauzuli (i oczywiście tam JOINidą elementy). Umieszczenie elementów łączących w WHEREklauzuli łączy w sobie to, co i skąd , dlatego JOINpreferowana jest składnia.

Stosowanie instrukcji warunkowych w ON / WHERE

Wyjaśniłem tutaj logiczne kroki przetwarzania zapytania.

Odniesienie: Wewnątrz Microsoft® SQL Server ™ 2005 Kwerenda T-SQL
Wydawca: Microsoft Press
Pub Data: 07 marca 2006
Drukuj ISBN-10: 0-7356-2313-9
Drukuj ISBN-13: 978-0-7356-2313-2
Strony: 640

Wewnątrz kwerendy T-SQL Microsoft® SQL Server ™ 2005

(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>

Pierwszym zauważalnym aspektem SQL innym niż inne języki programowania jest kolejność przetwarzania kodu. W większości języków programowania kod jest przetwarzany w kolejności, w jakiej został napisany. W SQL pierwszą przetwarzaną klauzulą ​​jest klauzula FROM, a klauzula SELECT, która pojawia się jako pierwsza, jest przetwarzana prawie na końcu.

Każdy krok generuje wirtualną tabelę, która jest używana jako dane wejściowe do następnego kroku. Te tabele wirtualne nie są dostępne dla osoby dzwoniącej (aplikacja kliencka lub zapytanie zewnętrzne). Tylko tabela wygenerowana przez ostatni krok jest zwracana do osoby dzwoniącej. Jeśli w zapytaniu nie podano określonej klauzuli, odpowiedni krok jest po prostu pomijany.

Krótki opis faz logicznego przetwarzania zapytania

Nie przejmuj się zbytnio, jeśli opis kroków wydaje się na razie bez sensu. Są one podane jako odniesienie. Sekcje, które pojawiają się po przykładzie scenariusza, będą omawiać kroki bardziej szczegółowo.

1. FROM: Produkt kartezjański (łączenie krzyżowe) jest wykonywany między dwiema pierwszymi tabelami w klauzuli FROM, w wyniku czego generowana jest wirtualna tabela VT1.

2. WŁ .: Filtr WŁ. Jest stosowany do VT1. Tylko wiersze, dla których <join_condition>jest PRAWDA, są wstawiane do VT2.

3. ZEWNĘTRZNE (złączenie): Jeśli określono ZŁĄCZE ZEWNĘTRZNE (w przeciwieństwie do ZŁĄCZA KRZYŻOWEGO lub DOŁĄCZENIA WEWNĘTRZNEGO), wiersze z zachowanej tabeli lub tabel, dla których nie znaleziono dopasowania, są dodawane do wierszy z VT2 jako wiersze zewnętrzne, generując VT3. Jeśli w klauzuli FROM pojawiają się więcej niż dwie tabele, kroki od 1 do 3 są powtarzane między wynikiem ostatniego łączenia i następnej tabeli w klauzuli FROM, aż wszystkie tabele zostaną przetworzone.

4. GDZIE: Filtr WHERE jest stosowany do VT3. Tylko wiersze, dla których <where_condition>jest PRAWDA, są wstawiane do VT4.

5. GROUP BY: Wiersze z VT4 są ułożone w grupy na podstawie listy kolumn określonej w klauzuli GROUP BY. Generowane jest VT5.

6. CUBE | ROLLUP: Supergrupy (grupy grup) są dodawane do wierszy z VT5, generując VT6.

7. HAVING: Filtr HAVING jest stosowany do VT6. Tylko grupy, dla których <having_condition>jest PRAWDA, są wstawiane do VT7.

8. SELECT: Lista SELECT jest przetwarzana, generując VT8.

9. ODRÓŻNIJ: Zduplikowane wiersze są usuwane z VT8. VT9 jest generowany.

10. ORDER BY: Wiersze z VT9 są sortowane zgodnie z listą kolumn określoną w klauzuli ORDER BY. Generowany jest kursor (VC10).

11. TOP: Określona liczba lub procent wierszy jest wybierana od początku VC10. Tabela VT11 jest generowana i zwracana do osoby dzwoniącej.

(Zastosowanie instrukcji warunkowych w ON / WHERE nie zrobi dużej różnicy w kilku przypadkach. Zależy to od liczby połączonych tabel i liczby wierszy dostępnych w każdej tabeli łączenia)

Domyślna składnia ANSI łączenia jest starsza, mniej oczywista i nie jest zalecana.

Ponadto algebra relacyjna umożliwia wymienność predykatów w WHEREklauzuli i INNER JOINtak, więc nawet INNER JOINzapytania z WHEREklauzulami mogą przestawiać predykaty przez optymalizator.

Polecam pisanie zapytań w możliwie najbardziej czytelny sposób.

Czasami obejmuje to uczynienie INNER JOINwzględnie „niekompletnym” i umieszczenie niektórych kryteriów w WHEREcelu ułatwienia zarządzania listami kryteriów filtrowania.

Na przykład zamiast:

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

Pisać:

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

Ale to oczywiście zależy.

Sprzężenia niejawne (tak zwane jest twoje pierwsze zapytanie) stają się znacznie bardziej mylące, trudne do odczytania i trudne do utrzymania, gdy zaczniesz dodawać kolejne tabele do zapytania. Wyobraź sobie, że wykonanie tego samego zapytania i typu łączenia na czterech lub pięciu różnych stołach ... to koszmar.

Używanie jawnego łączenia (twój drugi przykład) jest znacznie bardziej czytelne i łatwe w utrzymaniu.

Zaznaczę również, że stosowanie starszej składni jest bardziej podatne na błędy. Jeśli użyjesz sprzężenia wewnętrznego bez klauzuli ON, pojawi się błąd składniowy. Jeśli użyjesz starszej składni i zapomnisz o jednym z warunków łączenia w klauzuli where, otrzymasz sprzężenie krzyżowe. Programiści często naprawiają to, dodając wyraźne słowo kluczowe (zamiast naprawiać złączenie, ponieważ wciąż nie zdają sobie sprawy, że samo złączenie jest zepsute), które może wydawać się leczyć problem, ale znacznie spowalnia zapytanie.

Dodatkowo, jeśli chodzi o konserwację, jeśli masz sprzężenie krzyżowe w starej składni, skąd opiekun będzie wiedział, czy miałeś je mieć (są sytuacje, w których potrzebne są sprzężenia krzyżowe), czy też to powinien być wypadek?

Pozwól, że wskażę ci to pytanie, aby zobaczyć, dlaczego domyślna składnia jest zła, jeśli używasz lewych złączeń. Sybase * = do Ansi Standard z 2 różnymi zewnętrznymi stołami dla tego samego wewnętrznego stołu

Plus (tutaj osobisty rant), standard używający jawnych złączeń ma ponad 20 lat, co oznacza, że ​​domyślna składnia złączeń jest nieaktualna przez te 20 lat. Czy napiszesz kod aplikacji przy użyciu składni, która jest nieaktualna od 20 lat? Dlaczego chcesz napisać kod bazy danych?

Mają inne znaczenie dla ludzi.

Jednak w zależności od optymalizatora zapytań mogą mieć to samo znaczenie dla komputera.

Należy zawsze kodować, aby był czytelny.

To znaczy, jeśli jest to wbudowana relacja, użyj jawnego łączenia. jeśli dopasowujesz słabo powiązane dane, użyj klauzuli where.

Standard SQL: 2003 zmienił niektóre reguły pierwszeństwa, więc instrukcja JOIN ma pierwszeństwo przed złączeniem „przecinkiem”. To może faktycznie zmienić wyniki zapytania w zależności od jego konfiguracji. Powoduje to pewne problemy dla niektórych osób, gdy MySQL 5.0.12 przeszedł na przestrzeganie standardu.

W twoim przykładzie twoje zapytania działałyby tak samo. Ale jeśli dodałeś trzecią tabelę: WYBIERZ ... Z tabeli 1, tabela 2 DOŁĄCZ do tabeli 3 WŁ ... GDZIE ...

W wersjach wcześniejszych niż MySQL 5.0.12 najpierw dołączyła tabela 1 i tabela 2, a następnie tabela 3. Teraz (5.0.12 i nowsze) najpierw łączone są tabela 2 i tabela 3, a następnie tabela 1. Nie zawsze zmienia to wyniki, ale może i możesz nawet nie zdawać sobie z tego sprawy.

Nigdy nie używam już składni „przecinek”, wybierając drugi przykład. W każdym razie jest o wiele bardziej czytelny, warunki JOIN są z JOIN-ami, a nie oddzielnymi sekcjami zapytań.

Wiem, że mówisz o MySQL, ale i tak: W Oracle 9 sprzężenia jawne i niejawne generowałyby różne plany wykonania. AFAIK, który został rozwiązany w Oracle 10+: nie ma już takiej różnicy.

Składnia złączenia ANSI jest zdecydowanie bardziej przenośna.

Przechodzę aktualizację Microsoft SQL Server, a także wspomnę, że składnia = * i * = dla sprzężeń zewnętrznych w SQL Server nie jest obsługiwana (bez trybu zgodności) dla serwera SQL 2005 i późniejszych.

Jeśli często programujesz dynamiczne procedury składowane, zakochasz się w drugim przykładzie (używając where). Jeśli masz różne parametry wejściowe i dużo bałaganu morfologicznego, to jest to jedyny sposób. W przeciwnym razie oba będą uruchamiać ten sam plan zapytań, więc zdecydowanie nie ma oczywistej różnicy w klasycznych zapytaniach.