C'è qualche differenza sostanziale tra le query unite dalle clausole WHERE e le query che utilizzano un JOIN effettivo?

In Learn SQL the Hard Way (esercizio sei) , l'autore presenta la seguente query:

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";

e poi continua dicendo che:

Esistono in realtà altri modi per far funzionare questi tipi di query chiamate "join". Sto evitando questi concetti per ora perché sono follemente confusi. Atteniti a questo modo di unirti ai tavoli per ora e ignora le persone che cercano di dirti che questo è in qualche modo più lento o "di bassa classe".

È vero? Perché o perché no?

Con l'approccio dell'autore, insegnare OUTER JOINs sarà molto più difficile. La clausola ON di INNER JOIN non mi ha mai fatto impazzire come molte altre cose. Forse è perché non ho mai imparato alla vecchia maniera. Mi piacerebbe pensare che ci sia una ragione per cui ce ne siamo sbarazzati e non doveva essere compiaciuto e chiamare questo metodo di classe bassa.

È vero nello scenario molto ristretto che l'autore ha creato:

• Tale entry level di SQL che l'utilizzo di ON è complesso
• Considerando solo JOIN / INNER JOIN e non eventuali JOU ESTERNI
• Il programmatore isolato che non deve leggere il codice altrui né avere persone con esperienza nell'uso di ON che legge / utilizza il proprio codice.
• Non richiede query complesse con molte: tabelle, if's, ma's e o's.

Come parte di una progressione dell'insegnamento, penso che sia più facile scomporlo e avere una progressione naturale:

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

I concetti di unione e filtro delle tabelle non sono realmente gli stessi. Imparare la sintassi corretta ora avrà più riporto quando si impara outer join a meno che l'autore intende sull'insegnamento obsoleti cose / deprecate come: *= or =*.

Se è più lento dipende dallo Strumento per ottimizzare le query e da come semplifica la query (ciò che scrivi non è in realtà ciò che viene eseguito). Tuttavia, il grosso problema di questa citazione è che ignora completamente il fatto che ci sono diversi tipi di join che funzionano in modo completamente diverso. Ad esempio, ciò che viene detto è (teoricamente) vero per inner joins, ma non vale per outer joins( left joinse right joins).

L'autore presenta un semplice caso in cui è possibile utilizzare la sintassi precedente o nuova. Non sono d'accordo sulla sua affermazione che i join sono follemente confusi, perché unire le tabelle è un concetto di query SQL fondamentale. Quindi, forse l'autore avrebbe dovuto dedicare un po 'di tempo prima a spiegare come funzionano i JOIN prima di pronunciare un'istruzione supponente e fare un esempio di query con più tabelle.

Si dovrebbe usare la sintassi più recente. L'argomento principale per questo è che la tua query avrà:

• Seleziona i criteri
• Unisciti ai criteri
• Criteri di filtro

Utilizzando il vecchio stile, i criteri di join e filtro vengono combinati, il che in casi più complessi può creare confusione.

Inoltre, è possibile ottenere un prodotto cartesiano dimenticando un criterio di join nella clausola del filtro:

 person_pet.person_id = person.id

usando la sintassi precedente.

L'uso della sintassi più recente specifica anche come dovrebbe avvenire il join, il che è importante se si desidera un INNER, LEFT OUTER, ecc., Quindi è più esplicito per quanto riguarda la sintassi JOIN che IMHO aumenta la leggibilità per coloro che non hanno familiarità con le tabelle di join.

Non dovrebbe esserci, il parser di query dovrebbe generare una rappresentazione interna equivalente per query equivalenti indipendentemente da come sono scritte. L'autore sta solo usando la sintassi pre-SQL-92, motivo per cui afferma che potrebbe essere visto come "vecchio stile" o "bassa classe". Internamente, il parser e l'ottimizzatore dovrebbero generare lo stesso piano di query.

Ho imparato SQL in questo modo, inclusa la *=sintassi per i join esterni. Per me, è stato molto intuitivo poiché tutte le relazioni hanno avuto la stessa precedenza e ha svolto un lavoro migliore nell'impostare le query come una serie di domande: cosa vuoi? Da dove le vuoi? Quali vuoi?

Facendo la joinsintassi, interrompe il processo di pensiero verso le relazioni più fortemente. E personalmente trovo il codice molto meno leggibile con le tabelle e le relazioni mescolate.

Almeno in MSSQL, non c'è alcuna differenza significativa nelle prestazioni delle query, supponendo che tu usi lo stesso ordinamento di join. Detto questo, c'è un chiaro, enorme problema con l'apprendimento (e l'utilizzo) di SQL in questo modo. Se dimentichi una delle tue relazioni, otterrai prodotti incrociati inaspettati. Che su un database di qualsiasi dimensione non banale è proibitivamente costoso (e pericoloso per i non-seletti!). È molto più difficile dimenticare una relazione quando si utilizza la joinsintassi dello stile.

Esistono due aspetti diversi da considerare: prestazioni e manutenibilità / leggibilità .

Manutenibilità / Leggibilità

Ho scelto una query diversa, in quanto è qualcosa che penso sia un esempio migliore / peggiore della query originale che hai pubblicato.

Cosa ti sembra migliore ed è più leggibile?

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';

O...

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';

Per me personalmente, il primo è abbastanza leggibile. Vedete che stiamo unendo le tabelle INNER JOIN, il che significa che stiamo estraendo le righe corrispondenti alla successiva clausola di join (ovvero "unisciti a Employee con EmployeeDepartmentHistory su BusinessEntityID e includiamo quelle righe").

Quest'ultima, la virgola non significa nulla per me. Mi chiedo cosa stai facendo con tutti quei WHEREpredicati della clausola.

Il primo legge di più come pensa il mio cervello. Guardo SQL tutto il giorno ogni giorno e le virgole per i join. Il che mi porta al prossimo punto ...

Esistono in realtà altri modi per far funzionare questi tipi di query chiamate "join"

Sono tutti uniti. Anche le virgole sono un join. Il fatto che l'autore non li chiami è davvero la loro rovina ... non è ovvio. Dovrebbe essere ovvio. Stai unendo i dati relazionali, sia che tu specifichi JOINo ,.

Prestazione

Questo dipenderà sicuramente da RDBMS. Posso parlare solo per conto di Microsoft SQL Server. Per quanto riguarda le prestazioni, questi sono equivalenti. Come lo sai? Cattura i piani di post-esecuzione e guarda cosa sta facendo esattamente SQL Server per ciascuna di queste affermazioni:

Nell'immagine sopra, ho evidenziato che sto usando entrambe le query come sopra, differendo solo per i caratteri espliciti per il join ( JOINvs ,). SQL Server fa esattamente la stessa cosa.

Sommario

Non utilizzare le virgole. Usa JOINdichiarazioni esplicite .

No, non è affatto vero. L'autore sta creando confusione nei suoi lettori e incoraggiando la programmazione cargo-cult che evita una differenza strutturale molto potente tra la sintassi standard e questa variante precedente che preferisce. In particolare, una clausola WHERE ingombra rende più difficile capire cosa rende speciale la sua query.

Il suo esempio porta un lettore a generare una mappa mentale del suo significato che ha un sacco di disordine.

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";

All'incirca, quanto sopra è:

Ottieni l'ID dell'animale, NAME, AGE e DEAD per tutti gli animali domestici, person_pet e le persone in cui l'ID dell'animale corrisponde a un pet_id di un person_pet e l'identificativo person di quel record corrisponde al person_id di una persona il cui FIRST_NAME è "Zed"

Con una mappa mentale del genere, il lettore (che sta scrivendo l'SQL a mano per qualche motivo) può facilmente commettere un errore, possibilmente omettendo una o più tabelle. E un lettore di codice scritto in questo modo dovrà lavorare di più, per capire esattamente cosa sta cercando di fare l'autore SQL. ("Più difficile" è a livello di lettura di SQL con o senza l'evidenziazione della sintassi, ma è comunque una differenza maggiore di zero.)

C'è un motivo per cui i JOIN sono comuni, ed è il vecchio classico canard "separazione dei problemi". In particolare, per una query SQL c'è una buona ragione per separare come sono strutturati i dati rispetto a come vengono filtrati.

Se la query è stata scritta in modo più pulito, ad esempio

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";

Quindi il lettore ha una distinzione più chiara tra i componenti di ciò che viene richiesto. Il filtro distintivo di questa query è separato dal modo in cui i suoi componenti si relazionano tra loro e i componenti necessari di ogni relazione sono direttamente accanto al punto in cui sono richiesti.

Naturalmente, qualsiasi sistema di database moderno non dovrebbe vedere una differenza significativa tra i due stili. Ma se le prestazioni del database fossero l'unica considerazione, la query SQL non avrebbe nemmeno spazi bianchi o maiuscole.

Guy sta facendo un classico errore. Sta cercando di insegnare un concetto astratto con un'implementazione specifica. Non appena lo fai, entri in questo tipo di casino.

Avrei dovuto insegnare prima i concetti di base del database, quindi mostrare SQL come un modo per descriverli.

I join destro e sinistro, si potrebbe sostenere che non contano troppo. Outer Join, beh, potresti usare old *=e la =*sintassi.

Ora potresti sostenere che la sintassi è più semplice, ma solo per query semplici. Non appena inizi a provare a eseguire una query complessa con questa versione, puoi avere un disastro orribile. La "nuova" sintassi non è stata introdotta in modo da poter eseguire query complesse, è stato quindi eseguire query complesse in modo leggibile e quindi gestibile.

L'esempio è equivalente alla semplice riformulazione con JOIN interni. La differenza sta solo nelle possibilità aggiuntive che la sintassi JOIN consente. Ad esempio, è possibile specificare l'ordine in cui vengono elaborate le colonne delle due tabelle interessate; vedi ad esempio https://stackoverflow.com/a/1018825/259310 .

La saggezza ricevuta è, in caso di dubbio, scrivere le tue domande in modo da renderle più leggibili. Ma se le formulazioni JOIN o WHERE siano più facili da leggere sembra essere una questione di preferenza personale, motivo per cui entrambe le forme sono così diffuse.

Quando ho imparato SQL, i moduli INNER JOIN, LEFT JOIN, ecc. Non esistevano. Come hanno già affermato altre risposte, diversi dialetti di SQL avevano implementato join esterni usando una sintassi idiosincratica. Questa portabilità danneggiata del codice SQL. Riunire la lingua ha richiesto qualche cambiamento, e LEFT JOIN, ecc. È stato quello su cui si sono stabiliti.

È vero che per ogni INNER JOIN è possibile scrivere una virgola equivalente con la condizione di join nella clausola WHERE. Mi ci è voluto un po 'di tempo per migrare dal gradimento della vecchia forma alla preferenza della nuova forma. Apparentemente, l'autore di Learning SQL the Hard Way pensa ancora che il vecchio modo sia più semplice.

Ci sono differenze? Bene, sì, ci sono. Il primo è che un INNER JOIN con una clausola ON rivela l'intento dell'autore più chiaramente del vecchio stile. Il fatto che la clausola ON sia in effetti una condizione di join e non un altro tipo di restrizione è più evidente. Questo rende il codice che utilizza INNER JOIN più facile da imparare durante la lettura rispetto al vecchio stile. Questo è importante quando si mantiene il codice di qualcun altro.

La seconda differenza è che il nuovo stile rende leggermente più semplice per Query Optimizer scoprire la strategia vincente. Questo è un effetto molto piccolo, ma è reale.

La terza differenza è che quando impari a usare INNER JOIN (o semplicemente JOIN semplice), è più facile imparare LEFT JOIN, ecc.

A parte questo, non vi è alcuna differenza materiale.

Dipende se pensi in termini di set e logica formale .....

Se non si utilizza la parola chiave "join" si ottiene una progressione più semplice dalla logica formale a SQL.

Ma se come il 99% delle persone, non ti è piaciuta la logica formale nella tua laurea in matematica, allora la parola chiave join è più facile da imparare. SQL veniva presentato all'università come un altro modo per scrivere domande logiche formali ...