Per semplicità, supponiamo che tutti i campi rilevanti lo siano NOT NULL.

Tu puoi fare:

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

O altro:

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

Questi due funzionano allo stesso modo MySQL?

INNER JOIN è la sintassi ANSI che dovresti usare.

È generalmente considerato più leggibile, soprattutto quando si uniscono molti tavoli.

Può anche essere facilmente sostituito con un OUTER JOINogni volta che si presenta una necessità.

La WHEREsintassi è più orientata al modello relazionale.

Un risultato di due tabelle JOINed è un prodotto cartesiano delle tabelle a cui viene applicato un filtro che seleziona solo quelle righe con colonne di unione corrispondenti.

È più facile vederlo con la WHEREsintassi.

Come nel tuo esempio, in MySQL (e in SQL in generale) queste due query sono sinonimi.

Inoltre, MySQL ha anche una STRAIGHT_JOINclausola.

Usando questa clausola, puoi controllare l' JOINordine: quale tabella viene scansionata nel loop esterno e quale si trova nel loop interno.

Non puoi controllarlo in MySQL usando la WHEREsintassi.

Altri hanno sottolineato che INNER JOINaiuta la leggibilità umana, e questa è una priorità assoluta, sono d'accordo.
Vorrei provare a spiegare perché la sintassi del join è più leggibile.

Una SELECTquery di base è questa:

SELECT stuff
FROM tables
WHERE conditions

La SELECTclausola ci dice che cosa stiamo tornando; la FROMclausola ci dice da dove la stiamo ottenendo e la WHEREclausola ci dice da quali stiamo ricevendo.

JOIN è una dichiarazione sulle tabelle, su come sono legate insieme (concettualmente, in realtà, in una singola tabella).

Qualsiasi elemento di query che controlla le tabelle - da cui stiamo ottenendo elementi - appartiene semanticamente alla FROMclausola (e, naturalmente, è lì JOINche vanno gli elementi). Inserendo elementi di giunzione nella WHEREclausola si fondono il quale e il da dove , ecco perché JOINsi preferisce la sintassi.

Applicazione di dichiarazioni condizionali in ON / DOVE

Qui ho spiegato le fasi di elaborazione della query logica.

Riferimento: Inside Microsoft® SQL Server ™ 2005 T-SQL Querying
Editore: Microsoft Press
Pub Data: 07 marzo 2006
Stampa ISBN-10: 0-7356-2313-9
Stampa ISBN-13: 978-0-7356-2313-2
Pagine: 640

All'interno di query T-SQL di 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>

Il primo aspetto evidente di SQL diverso dagli altri linguaggi di programmazione è l'ordine in cui il codice viene elaborato. Nella maggior parte dei linguaggi di programmazione, il codice viene elaborato nell'ordine in cui è scritto. In SQL, la prima clausola che viene elaborata è la clausola FROM, mentre la clausola SELECT, che appare per prima, viene elaborata quasi per ultima.

Ogni passaggio genera una tabella virtuale che viene utilizzata come input per il passaggio successivo. Queste tabelle virtuali non sono disponibili per il chiamante (applicazione client o query esterna). Solo la tabella generata dal passaggio finale viene restituita al chiamante. Se una determinata clausola non viene specificata in una query, il passaggio corrispondente viene semplicemente ignorato.

Breve descrizione delle fasi di elaborazione delle query logiche

Non preoccuparti troppo se la descrizione dei passaggi non sembra avere molto senso per ora. Questi sono forniti come riferimento. Le sezioni che seguono l'esempio dello scenario copriranno i passaggi in modo molto più dettagliato.

1. FROM: un prodotto cartesiano (cross join) viene eseguito tra le prime due tabelle nella clausola FROM e, di conseguenza, viene generata la tabella virtuale VT1.

2. ON: il filtro ON viene applicato a VT1. Solo le righe per le quali <join_condition>è TRUE vengono inserite in VT2.

3. OUTER (join): se viene specificato un OUTER JOIN (al contrario di un CROSS JOIN o un INNER JOIN), le righe della tabella conservata o le tabelle per le quali non è stata trovata una corrispondenza vengono aggiunte alle righe da VT2 come righe esterne, generando VT3. Se vengono visualizzate più di due tabelle nella clausola FROM, i passaggi da 1 a 3 vengono applicati ripetutamente tra il risultato dell'ultimo join e la tabella successiva nella clausola FROM fino a quando non vengono elaborate tutte le tabelle.

4. DOVE: il filtro DOVE viene applicato a VT3. Solo le righe per le quali <where_condition>è TRUE vengono inserite in VT4.

5. GROUP BY: le righe da VT4 sono organizzate in gruppi in base all'elenco di colonne specificato nella clausola GROUP BY. Viene generato VT5.

6. CUBE | ROLLUP: i supergruppi (gruppi di gruppi) vengono aggiunti alle righe da VT5, generando VT6.

7. HAVING: il filtro HAVING viene applicato a VT6. Solo i gruppi per i quali <having_condition>è TRUE vengono inseriti in VT7.

8. SELECT: l'elenco SELECT viene elaborato, generando VT8.

9. DISTINCT: le righe duplicate vengono rimosse da VT8. Viene generato VT9.

10. ORDER BY: le righe da VT9 sono ordinate in base all'elenco di colonne specificato nella clausola ORDER BY. Viene generato un cursore (VC10).

11. INIZIO: il numero o la percentuale di righe specificati è selezionato dall'inizio di VC10. La tabella VT11 viene generata e restituita al chiamante.

(L'applicazione delle istruzioni condizionali in ON / DOVE non farà molta differenza in alcuni casi. Ciò dipende dal numero di tabelle che sono state unite e dal numero di righe disponibili in ciascuna tabella dei join)

La sintassi ANSI di join implicita è più vecchia, meno ovvia e sconsigliata.

Inoltre, l'algebra relazionale consente l'interscambiabilità dei predicati nella WHEREclausola e la INNER JOIN, quindi anche le INNER JOINquery conWHERE clausole possano riorganizzare i predicati dall'ottimizzatore.

Ti consiglio di scrivere le domande nel modo più leggibile possibile.

A volte questo include rendere INNER JOINrelativamente "incompleto" e mettere alcuni dei criteri nelWHERE semplicemente per rendere più facilmente gestibili gli elenchi dei criteri di filtro.

Ad esempio, anziché:

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

Scrivi:

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

Ma dipende, ovviamente.

I join impliciti (che è noto come la tua prima query) diventano molto più confusi, difficili da leggere e difficili da mantenere una volta che devi iniziare ad aggiungere più tabelle alla tua query. Immagina di fare la stessa query e lo stesso tipo di join su quattro o cinque diversi tavoli ... è un incubo.

L'uso di un join esplicito (il tuo secondo esempio) è molto più leggibile e facile da mantenere.

Sottolineerò inoltre che l'utilizzo della sintassi precedente è più soggetto a errori. Se si utilizzano join interni senza una clausola ON, verrà visualizzato un errore di sintassi. Se usi la sintassi precedente e dimentichi una delle condizioni di join nella clausola where, otterrai un cross join. Gli sviluppatori spesso risolvono questo problema aggiungendo la parola chiave distinta (anziché correggere il join perché non si rendono ancora conto che il join stesso è interrotto) che potrebbe sembrare risolvere il problema, ma rallenterà notevolmente la query.

Inoltre, per la manutenzione se si dispone di un cross join nella vecchia sintassi, come farà il manutentore a sapere se si intende averne uno (ci sono situazioni in cui sono necessari cross join) o se si è trattato di un incidente che deve essere risolto?

Permettetemi di indicarvi questa domanda per capire perché la sintassi implicita è errata se usate i join di sinistra. Sybase * = secondo lo standard Ansi con 2 diversi tavoli esterni per lo stesso tavolo interno

Inoltre (personale rant qui), lo standard che utilizza i join espliciti ha più di 20 anni, il che significa che la sintassi dei join impliciti è stata superata per questi 20 anni. Scriveresti il ​​codice dell'applicazione usando una sintassi obsoleta da 20 anni? Perché vuoi scrivere il codice del database che è?

Hanno un diverso significato leggibile dall'uomo.

Tuttavia, a seconda di Query Optimizer, potrebbero avere lo stesso significato per la macchina.

Dovresti sempre programmare per essere leggibile.

Vale a dire, se si tratta di una relazione incorporata, utilizzare il join esplicito. se si esegue la corrispondenza su dati debolmente correlati, utilizzare la clausola where.

Lo standard SQL: 2003 ha modificato alcune regole di precedenza in modo che un'istruzione JOIN abbia la precedenza su un join "virgola". Ciò può effettivamente modificare i risultati della query in base alla configurazione. Ciò causa alcuni problemi ad alcune persone quando MySQL 5.0.12 è passato all'adesione allo standard.

Quindi, nel tuo esempio, le tue domande funzionerebbero allo stesso modo. Ma se hai aggiunto una terza tabella: SELEZIONA ... DA table1, table2 UNISCITI table3 SU ... DOVE ...

Prima di MySQL 5.0.12, table1 e table2 venivano prima uniti, quindi table3. Ora (5.0.12 e successivi), table2 e table3 vengono unite prima, quindi table1. Non cambia sempre i risultati, ma può e potresti anche non rendertene conto.

Non uso più la sintassi "virgola", optando per il tuo secondo esempio. È comunque molto più leggibile, le condizioni JOIN sono con i JOIN, non separate in una sezione di query separata.

So che stai parlando di MySQL, ma comunque: in Oracle 9 i join espliciti e i join impliciti genererebbero piani di esecuzione diversi. AFAIK che è stato risolto in Oracle 10+: non c'è più tale differenza.

La sintassi del join ANSI è sicuramente più portatile.

Sto attraversando un aggiornamento di Microsoft SQL Server e vorrei anche menzionare che la sintassi = * e * = per i join esterni in SQL Server non è supportata (senza modalità di compatibilità) per il server sql 2005 e versioni successive.

Se stai spesso programmando stored procedure dinamiche, ti innamorerai del tuo secondo esempio (usando where). Se hai vari parametri di input e un sacco di confusione, questo è l'unico modo. In caso contrario, entrambi eseguiranno lo stesso piano di query, quindi non vi è alcuna differenza evidente nelle query classiche.