Ha l'ordine delle espressioni o predicati fa alcuna differenza nella condizione di join per outer join in SQL standard?

voti
2

Così sto avendo un po 'di una giornata frustrante. Sono stato licenziato da un contratto avevo lavorato nelle ultime settimane, perché non l'ho fatto maglia con la squadra. Due esempi sono stati citati:

1) Ieri mi è stato chiesto di cancellare tutti i dati da un database di SQL Server ad eccezione di alcuni dati di sistema di base. Il richiedente (non il mio capo) aveva circa otto script che aveva usato per questo compito a pochi mesi fa. A quanto pare nessuno ha mai pensato allo script fuori il modello di dati o dati di sistema.

Questa persona aveva stabilito un modello di eccesso di complicare le cose, così mi è stato cercare di capire le ragioni del compito e l'obiettivo finale. Ho anche faticato a capire perché ha sempre avuto tutti i tipi di errori vaghi che ha richiesto tutti questi script aggiuntivi a rimuovere e aggiungere nuovamente i vincoli.

Ero abbastanza disposto a fare tutto il necessario e abbiamo parlato per diversi minuti su di esso. Per ovvi motivi ho pensato che cercare di capire il motivo per cui è stata una buona cosa. Improvvisamente decise che sarebbe solo essere più veloce per farlo da sola piuttosto che passare il tempo a spiegare tutto a me e sono tornato al mio altro lavoro senza pensare più su di esso.

In qualche modo questo è stato interpretato negativamente.

2) Alcune settimane fa durante la mia prima settimana mi è stato chiesto di lavorare su fusione di alcuni dati da un altro sistema. Mi è stato dato un copione 600+ linea di frammenti SQL che tutto sembrava essere importante insieme ad un tirata orale di lamentele su dati scarsi e programmatori originali. Naturalmente ci sono voluti un po 'di tempo di guadare attraverso stretto contatto, ma dopo un paio di giorni il mio risultato finale è emerso come una semplice unione in circa 25 righe.

Ho scritto di SQL per più di dieci anni e mi considero di avere qualche competenza nel settore. I miei colleghi erano sempre un po 'impaziente, come ho sfogliato via gli strati di complessità inutile e io siamo stati in ritardo per finire il compito, come promesso.

Non ero sicuro di come facilmente si sarebbero accettare che la soluzione del problema sembrava essere esattamente un comando molto breve e mi chiedevo se mi mancava qualcosa che sarebbe rivelarsi imbarazzante. Purtroppo tutte le mie domande di sondaggio era stato più volte incontrato con il tipo di non-risposte sprezzanti che gli insegnanti poveri danno ad uno studente elementare eccessivamente curioso. Così ho inviato la query lungo in un'email e tornai a casa.

La mattina dopo mi è stato detto (stessa persona # 1) che era tutto sbagliato, ma era roba che non ci si poteva aspettare di sapere come il nuovo ragazzo. Mi ha spiegato che doveva trattenersi dal riscrivere tutto. Uno dei suoi punti era qualcosa di minore sui dati che avevo già destinati a chiederle di me stesso. L'altro era puramente SQL.

(La domanda inizia da qui.)

Prendete un tipico scenario di join esterno sinistro. Sappiamo tutti che l'ordine delle tabelle è abbastanza significativo, ad esempio, Q1 e Q2 non sono equivalenti:

SELECT A.x, B.y FROM A LEFT OUTER JOIN B ON A.id = B.id -- (Q1)
SELECT A.x, B.y FROM B LEFT OUTER JOIN A ON B.id = A.id -- (Q2)

Quando penso concettualmente su più join di solito sembra naturale per me immaginare raccogliendo la nuova tabella come oggetto di interesse e poi descrivendo come le sue file sono legati a ciò che è venuto prima. Mantenere i termini in parallelo non ha alcun vantaggio per me e per la mia abitudine io in genere scrivo la condizione di join in questo modo:

SELECT A.x, B.y FROM A LEFT OUTER JOIN B ON B.id = A.id -- (Q3)

Così mi ritrovo a essere istruito su come l'ordine delle tabelle questioni in un outer join. Avevo pensato questa prova della mia intelligenza è già stato fatto durante il colloquio di lavoro. La mia confusione si trasformò in stupore quando mi resi conto che stava concentrando solo sul confronto di uguaglianza. Per lei Q3 era sbagliato e Q1 è stata la versione di cui avevo bisogno, invece.

I diplomaticamente insistito sul fatto che essa non ha fatto alcuna differenza a tutti e che avrei potuto facilmente dimostrare il mio caso se voleva. Ho cercato di chiarire il suo ragionamento, ma questo è il tipo di persona che non ascoltano con attenzione alle vostre domande, non importa con quanta cura sono formulati o quante parole tecniche che si utilizzano per suggerire un piccolo livello di competenza, così ho deciso che ho appena non riusciva a convincerla che non sono un idiota. E ho accettato di cambiare la sceneggiatura perché non valeva la pena discutere su.

Suppongo che non subito ingoiare il mio orgoglio ha dimostrato che non ero coachable.


Per quanto riguarda lo stile da sola, mi sono conformi a qualsiasi standard del datore di lavoro preferisce anche se il loro SQL è spesso sciatta in altri modi. Lo faccio riconoscere che con il vecchio stile outer join sintassi questo sarebbe un problema. Al di là che non ho mai sentito nessuno fare questo caso. Si prega di rispondere a questa domanda e riscattare la mia reputazione.

Ha l'ordine delle espressioni o predicati fa alcuna differenza nella condizione di join per outer join in SQL standard?

È pubblicato 07/07/2012 alle 01:54
dall'utente
In altre lingue...                            


4 risposte

voti
2

L'ordine del confronto di uguaglianza fa alcuna differenza per i risultati del join. Ma potrebbe, per ragioni imperscrutabili influenzare l'efficienza con la quale il risultato viene calcolato. ottimizzatori SQL sono noti per essere colpiti da dettagli apparentemente poco importanti come questo.

Risposto il 07/07/2012 a 02:04
fonte dall'utente

voti
4

No, non fa alcuna differenza.

Personalmente preferisco lo stile che si mostra in Q3, alcuni dei miei compagni di lavoro preferiscono lo stile in Q1. Io non conosco nessuno che avrebbe mai prendere in considerazione sia di loro di essere sbagliato .

L'ottimizzatore di query trasforma la query dentro e fuori in qualcosa di completamente diverso, in modo che il predicato non esiste nemmeno come un confronto più semplice quando è fatto con esso. Di solito si tratta di una ricerca in un indice o una tabella, e come che può essere fatto solo in una direzione, come il predicato è stato scritto non fa alcuna differenza.

Ho controllato (in SQL Server 2005) il piano di esecuzione di due query con gli operandi predicato in ordine diverso, e come previsto sono identici.

Risposto il 07/07/2012 a 02:21
fonte dall'utente

voti
2

Io preferisco Q3 del Partecipa ordine Condizione anche:

... ON B.id = A.id -- (Q3)

Come si riflette direttamente che il B.id è la più varia uno, si può pensare di A.id come l'essere costantemente testati contro, ad esempio,

B.id = 1984

Allo stesso modo che io non voglio vedere questo in codice ...

1984 = B.id

..., come te non voglio vedere questo in query:

A.id = B.id

Tuttavia, come la maggior parte delle cose nella vita, ci sono persone che amano little-endian, e ci sono quelli che amano big-endian. Qualunque modello mentale li può servire delle preferenze che hanno scelto, dovrebbero essere almeno in grado di spiegare a voi la ragione perché volevanoA.id = B.id

Penso, devo cambiare la mia preferenza, però, il mio (e vostro) preferito ordine Condizione non funziona in alcune ORM, Linq in particolare. Devo ancora capire perché esse impongono che la condizione deve essere in ordine di Q1:

from x in A
join y in B on x.id equals y.id

E invertire la condizione (stessa Q3, se nella query SQL non è un errore) Risultati fine di errore di sintassi, questo non sarà accettata dalla Linq:

from x in A
join y in B on y.id equals x.id

Ora, devo trovare la ragione per cui i progettisti Microsoft Linq preferivano l'ordine del condizione di Q1. E cercare di apprezzare se ha senso, e solo accettare anche se non ha (ancora) ha un senso.


Per quanto riguarda:

Ha l'ordine delle espressioni o predicati fa alcuna differenza nella condizione di join per outer join in SQL standard?

Risultati-saggio, NO . Performance-saggio, devo ancora vedere una query in cui il join ordine condizione rende la query più veloce. Anche nei forum non ho visto nessuno sostiene invertire la condizione per rendere la query più veloce.

Se non possono spiegare a voi la logica o il modello mentale dell'ordine di loro condizione preferita serve forse sono semplicemente facendo Cargo Cult di programmazione o, peggio ancora, Bikeshedding

Risposto il 07/07/2012 a 02:48
fonte dall'utente

voti
1

Io preferisco il tuo Q1, tuttavia fa alcuna differenza in termini di prestazioni e non ha assolutamente alcun effetto sul Query Optimizer.

Per me, mettere al primo posto la tabella precedente mi dà le informazioni rilevanti prima nel mio processo di scansione. Posso leggere join table B on A ...e sanno già che due tabelle vengono unite insieme. Quando ho letto join table B on B.blasdjasdid = ...che ho dovuto eseguire la scansione molto più lontano e ancora non so le informazioni più importanti, quale tabella viene unita ad (che è una sorta di spazio dei nomi, un dominio in cui sarà capito il nome della colonna). Inoltre, se le colonne sono lo stesso nome in entrambe le tabelle (idiomatiche in qualsiasi progettazione di database I), posso evitare di scansione fino alla fine del tutto, solo lettura join table B on A.SomethingId ...e già sapendo che è = B.SomethingId.

Andando un po 'più profonda, vi incoraggio a chiedere informazioni su questo evento sul workplace.stackexchange.com perché ho il sospetto che le ragioni vostri servizi sono stati sospesi non corrispondono che ti hanno detto; qualche indagine in questo potrebbe essere produttivo. Non sto suggerendo che è stata colpa tua, ma che il motivo è probabile che un pretesto.

Risposto il 29/12/2015 a 19:14
fonte dall'utente

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more