SQL LEFT join vs wiele tabel on FROM line?

Składnia JOIN zachowuje warunki w pobliżu tabeli, do której mają zastosowanie. Jest to szczególnie przydatne, gdy dołączysz do dużej liczby stołów.

Przy okazji, możesz też wykonać zewnętrzne połączenie z pierwszą składnią:

WHERE a.x = b.x(+)

Lub

WHERE a.x *= b.x

Lub

WHERE a.x = b.x or a.x not in (select x from b)

Pierwszy sposób to starszy standard. Druga metoda została wprowadzona w SQL-92, http://en.wikipedia.org/wiki/SQL . pełny standard można obejrzeć pod adresem http://www.contrib.andrew.cmu.edu / ~shadow/sql/sql1992.txt .

Minęło wiele lat, zanim firmy bazodanowe przyjęły standard SQL-92.

Więc powodem, dla którego druga metoda jest preferowana, jest to standard SQL według Komitetu standardów ANSI i ISO.

Drugi jest preferowany, ponieważ jest znacznie mniej prawdopodobne, że spowoduje przypadkowe połączenie krzyżowe, zapominając o umieszczeniu klauzuli where. Join z klauzulą no on nie sprawdzi składni, an old style join z klauzulą no where nie zawiedzie, wykona połączenie krzyżowe.

DODATKOWO, gdy później będziesz musiał połączyć się w lewo, pomocne dla utrzymania jest, aby wszystkie były w tej samej strukturze. A stara składnia jest nieaktualna od 1992 roku, nadszedł już dawno, aby przestać używać to.

Poza tym odkryłem, że wiele osób, które używają wyłącznie pierwszej składni, nie rozumie joinsów, a zrozumienie joinsów ma kluczowe znaczenie dla uzyskania poprawnych wyników podczas zapytań.

Zasadniczo, gdy klauzula FROM wyświetla tabele w ten sposób:

SELECT * FROM
  tableA, tableB, tableC

Wynik jest iloczynem krzyżowym wszystkich wierszy w tabelach A, B, C. następnie stosuje się ograniczenie WHERE tableA.id = tableB.a_id, które wyrzuci ogromną liczbę wierszy, a następnie dalej ... AND tableB.id = tableC.b_id i wtedy powinieneś dostać tylko te wiersze, które naprawdę Cię interesują.

DBMSs wie, jak zoptymalizować ten SQL, aby różnica wydajności w stosunku do zapisu tego za pomocą Joinsów była znikoma (jeśli w ogóle). Korzystanie z notacji JOIN sprawia, że SQL statement more readable (IMHO, nie używając joins zamienia wypowiedź w bałagan). Korzystając z iloczynu krzyżowego, musisz podać kryteria przyłączenia w klauzuli WHERE, i to jest problem z zapisem. Wypychasz swoją klauzulę WHERE takimi rzeczami jak

    tableA.id = tableB.a_id 
AND tableB.id = tableC.b_id 

Który jest używany tylko w celu ograniczenia iloczynu krzyżowego. Klauzula WHERE powinna zawierać jedynie ograniczenia dla resultset. Jeśli połączysz kryteria table join z ograniczeniami resultset, ty (i inni) znajdziesz swoje zapytanie trudniej czytać. Zdecydowanie powinieneś używać JOINs i zachować klauzulę FROM a klauzulę FROM oraz klauzulę WHERE a WHERE.

Myślę, że na tej stronie jest kilka dobrych powodów, aby przyjąć drugą metodę - używanie jawnych złączeń. Najważniejsze jest jednak to, że gdy kryteria przyłączenia są usuwane z klauzuli WHERE, znacznie łatwiej jest zobaczyć pozostałe kryteria wyboru w klauzuli WHERE.

W naprawdę złożonych wyrażeniach SELECT czytelnikowi znacznie łatwiej jest zrozumieć, co się dzieje.

Składnia SELECT * FROM table1, table2, ... jest ok dla kilku tabel, ale staje się wykładniczo ( niekoniecznie matematycznie dokładne stwierdzenie ) coraz trudniej odczytać, gdy liczba tabel rośnie.

Składnia JOIN jest trudniejsza do napisania (na początku), ale wyjaśnia, jakie kryteria wpływają na które tabele. To znacznie utrudnia popełnienie błędu.

Również, jeśli wszystkie połączenia są wewnętrzne, to obie wersje są równoważne. Jednak w momencie, gdy masz zewnętrzną dołącz w dowolnym miejscu w oświadczeniu, sprawy stają się znacznie bardziej skomplikowane i to praktycznie gwarantuje, że to, co piszesz, nie będzie pytaniem o to, co myślisz, że napisałeś.

Jeśli potrzebujesz zewnętrznego połączenia, druga składnia to NIE zawsze wymagane:

Wyrocznia:

SELECT a.foo, b.foo
  FROM a, b
 WHERE a.x = b.x(+)

MSSQLServer (chociaż został przestarzały w wersji 2000) / Sybase:

SELECT a.foo, b.foo
  FROM a, b
 WHERE a.x *= b.x

Słyszałem, że wiele osób skarży się, że pierwszy jest zbyt trudny do zrozumienia i że jest niejasny. Nie widzę z tym problemu, ale po tej dyskusji używam drugiego nawet na łączach wewnętrznych dla jasności.

Do bazy danych, w końcu są takie same. W niektórych sytuacjach będziesz musiał użyć tej drugiej składni. Ze względu na edytowanie zapytań, które kończą się koniecznością korzystania z niego (dowiadując się, że potrzebujesz lewego połączenia, gdzie masz proste połączenie), a dla spójności, chciałbym wzorzec tylko na 2. metodzie. Ułatwi to czytanie zapytań.

Cóż, pierwsze i drugie zapytania mogą dać różne wyniki, ponieważ lewe połączenie zawiera wszystkie rekordy z pierwszej tabeli, nawet jeśli nie ma odpowiednich rekordów w prawej tabeli.