2009-12-30 13 views
5

Non ho mai imparato come funzionano i join ma solo usando select e la clausola where è stata sufficiente per tutte le query che ho fatto. Ci sono casi in cui non riesco a ottenere i risultati corretti usando la clausola WHERE e devo usare un JOIN? Se sì, qualcuno potrebbe fornirci degli esempi? Grazie.Le query che i join SQL impliciti non possono eseguire?

+2

La risposta più semplice è: dovresti conoscere i JOIN. In molti casi, ti semplificheranno la vita, anche se c'è un altro modo per scrivere la tua domanda. –

+1

Ora una cosa molto buona per te sarebbe quella di imparare ad accettare le risposte date alle tue domande che sembrano corrette. Sento che le risposte non sono necessarie, o commentare le risposte date o piazzare una taglia. MK? –

risposta

3

Sì. Quando si fanno join esterni. Puoi leggere this simple article sui join. Le unioni non sono difficili da capire, quindi dovresti iniziare subito a imparare (e usarle dove opportuno).

+0

Non sono sicuro del motivo per cui è stato negativo. La risposta è morta ....... i join impliciti sono "interni" per impostazione predefinita. Quindi, il richiedente probabilmente ha bisogno di capire i diversi tipi di join. – tyshock

+0

Oggi sembra essere un giorno negativo. Ho visto diverse domande e risposte ridotte oggi con altre persone che pubblicano commenti "perché è stato modificato". – jeffa00

0

Ogni volta che si desidera combinare i risultati di due tabelle è necessario unirsi a loro. Prendiamo ad esempio:

tabella Utenti:

ID 
FirstName 
LastName 
UserName 
Password 

e indirizzi tavolo:

ID 
UserID 
AddressType (residential, business, shipping, billing, etc) 
Line1 
Line2 
City 
State 
Zip 

in cui un singolo utente potrebbe avere la sua casa e il suo indirizzo commerciale elencato (o di una spedizione e un indirizzo di fatturazione), o nessun indirizzo. L'utilizzo di una semplice clausola WHERE non recupera un utente senza indirizzi perché gli indirizzi si trovano in una tabella diversa. Al fine di recuperare gli indirizzi di un utente ora, avrete bisogno di fare una join as:

SELECT * 
FROM Users 
LEFT OUTER JOIN Addresses 
    ON Users.ID = Addresses.UserID 
WHERE Users.UserName = "foo" 

Vedi http://www.w3schools.com/Sql/sql_join.asp per un po 'di più nella definizione di profondità del diverso raggiunge e come funzionano.

+0

Non è necessario utilizzare 'inner join '. Puoi scriverlo come 'seleziona utenti. * Da utenti, indirizzi dove users.id = indirizzi.userid e users.username = "pippo" '. Ma questo non è il caso per i join esterni, come indicato nella mia risposta qui sotto. –

+1

@klausbyskov: Quel *** è un join interno, è solo sintassi ANSI-89. –

+0

Il mio male, è caduto nell'esempio sbagliato ... corretto ora: D –

0

Sintassi di join implicita per impostazione predefinita Inner joins. A volte è possibile modificare la sintassi di join implicita per specificare join esterni, ma è dipendente dal venditore nella mia esperienza (so che oracle ha la notazione (-) e (+), e credo che sqlserver usi * =). Quindi, credo che la tua domanda possa essere ridotta a comprendere le differenze tra join interni ed esterni.

Possiamo guardare un semplice esempio per un interno vs outer join utilizzando una query semplice ..........

L'implicita INNER JOIN:

select a.*, b.* 
from table a, table b 
where a.id = b.id; 

È possibile che questo interrogazione restituirà SOLO le righe in cui la riga 'a' ha una riga corrispondente in 'b' per il suo campo 'id'.

L'ESTERNO esplicita JOIN:

select * from 
table a LEFT OUTER JOIN table b 
on a.id = b.id; 

La query sopra riporterà ogni riga in una, anche se non ha una riga corrispondente in 'b'. Se non esiste alcuna corrispondenza per "b", i campi "b" saranno nulli.

In questo caso, se si desidera richiamare OGNI riga in 'a' indipendentemente dal fatto che avesse una riga 'b' corrispondente, sarà necessario utilizzare il join esterno.

Come ho detto, a seconda del fornitore del database, è ancora possibile utilizzare la sintassi implicita del join e specificare un tipo di join esterno. Tuttavia, questo ti lega a quel venditore. Inoltre, tutti gli sviluppatori che non hanno familiarità con la sintassi specializzata potrebbero avere difficoltà a comprendere la tua query.

2

Esistono casi in cui non è possibile ottenere i risultati corretti utilizzando la clausola WHERE e devo utilizzare un JOIN?

Ogni volta che la query riguarda due o più tabelle, viene utilizzato un join. This link è ottimo per mostrare le differenze nei join con le immagini e con i set di risultati del campione.

Se i criteri di join sono nella clausola WHERE, viene utilizzata la sintassi JOIN ANSI-89. La ragione della più recente sintassi JOIN nel formato ANSI-92 è che ha reso LEFT JOIN più coerente tra i vari database. Ad esempio, Oracle utilizzava (+) sul lato che era facoltativo mentre in SQL Server si doveva usare =*.

+0

E la sintassi di join implicita in SQl Server non è più valida e, anche nelle versioni precedenti, forniva risultati errati poiché a volte veniva interpretata come join esterno e talvolta come cross join. – HLGEM

0

utilizzando join:

SELECT a.MainID, b.SubValue AS SubValue1, b.SubDesc AS SubDesc1, c.SubValue AS SubValue2, c.SubDesc AS SubDesc2 
FROM MainTable AS a 
LEFT JOIN SubValues AS b ON a.MainID = b.MainID AND b.SubTypeID = 1 
LEFT JOIN SubValues AS c ON a.MainID = c.MainID AND b.SubTypeID = 2 

fuori mano, non riesco a vedere un modo di ottenere gli stessi risultati che, utilizzando una semplice clausola WHERE per unire le tabelle. Inoltre, la sintassi comunemente usata nelle clausole WHERE per creare join sinistro e destro (* = e = *) è in fase di eliminazione,

+0

(* = e = *) non solo viene eliminato gradualmente in SQL Server, ma al momento non restituisce sempre risultati corretti. – HLGEM

7

I join impliciti sono più di 20 anni non aggiornati. Perché dovresti prendere in considerazione la possibilità di scrivere codice con loro?

Sì, possono creare problemi che i join espliciti non hanno. Parlando di SQL Server, non è garantito che le sintassi implicite di join sinistro e destro restituiscano i risultati corretti. A volte, restituiscono un join incrociato anziché un join esterno. Questa è una brutta cosa Questo era vero almeno fino a SQL Server 2000, e sono stati eliminati gradualmente, quindi usarli è una pratica tutt'altro che semplice.

L'altro problema con join impliciti è che è facile eseguire accidentalmente un cross join dimenticando una delle condizioni in cui si trova, in particolare quando si uniscono troppe tabelle. Utilizzando i join espliciti, si verificherà un errore di sintassi se si dimentica di inserire una condizione di join e un cross join deve essere esplicitamente specificato come tale. Di nuovo, questo si traduce in query che restituiscono valori errati o che vengono risolti utilizzando distinti per sbarazzarsi del cross join che è inefficiente nella migliore delle ipotesi.

Inoltre, se si dispone di un cross join, lo sviluppatore di manutenzione che arriva in un anno per apportare una modifica non sa se è stato progettato o meno quando si utilizzano join impliciti.

Credo che alcuni ORM ora richiedano anche join espliciti.

Inoltre, se si utilizzano i join impliciti perché non si capisce come funzionano i join, è probabile che si stia scrivendo codice che, di fatto, non restituisce il risultato corretto perché non si sa come valutare quale sarebbe il risultato corretto dal momento che non capisci cosa si intende fare un join.

Se si scrive codice SQL di qualsiasi gusto, non ci sono scuse per non comprendere a fondo i join.

+0

FYI, 17 anni = superato dallo standard ANSI 92 SQL (e 18 anni domani :-) – gbn