Subinterogarilor am discutat pe scurt în subinterogările articol și tabele temporare. Aici vom arunca o privire mai atentă la tipul de sub-interogări asociate. Subinterogare este numit asociat (corelat). în cazul în care orice valoare subinterogare dependentă de cererea externă. Următorul exemplu ilustrează utilizarea unei subinterogări corelate:
În acest exemplu, o interogare imbricate trebuie să fie în mod logic, executate de mai multe ori, deoarece conține o coloană Id-ul, care face parte din tabelul angajaților în interogare exterioară, și valoarea coloana Id-ul se schimbă de fiecare dată când un rând diferit este verificat tabelul Angajat în interogare exterioară.
Să ne examinăm modul în care sistemul poate efectua o solicitare în acest exemplu. Sistemul selectează mai întâi un prim tabel rând angajatului (cerere externă) și compară numărul de personal angajat în această coloană (25,348) cu valorile coloanelor Works_on.EmpId subinterogare. În ceea ce privește acest angajat are doar o singură valoare egală p2 ProjectNumber, p2 interogare imbricate returnează valoarea. Acest singur rezultat valoarea subinterogare setată nu este egal cu valoarea de p3 interogare exterior, condiția de interogare exterioară (unde „p3“ IN.) Nu este îndeplinită, și, prin urmare, interogarea exterioară nu returnează rânduri pentru acest angajat.
Sistemul ia apoi următoarea linie la masă angajaților, și din nou compară numărul de angajați în ambele tabele. Pentru acest rând Works_on în tabel există două rânduri, pentru care valoarea este p1 ProjectNumber egală și p3, respectiv. Prin urmare, interogare imbricate returnează rezultatul p1 și p3. Valoarea unuia dintre elementele setului de rezultate este p3 constantă, prin urmare, condiția este îndeplinită, și afișează o valoare a doua linie coloană LastName ( „Frolov„). Aceeași procesare sunt supuse tuturor celorlalte rând al tabelului Employee, iar setul de rezultate finale este returnat din cele trei linii.
Următoarea secțiune furnizează exemple suplimentare de subinterogări corelate.
Subinterogarilor și EXISTS funcție
EXISTS funcția subinterogare preia ca argumente și returnează valoarea false, dacă interogarea returnează rânduri imbricate și valoare reală în alt mod. Luați în considerare performanța acestei funcții prin câteva exemple, începând cu următorul exemplu:
În acest exemplu, există un eșantion de numele tuturor angajaților care lucrează pe p1 proiectului. Subinterogare EXISTS funcția aproape întotdeauna depinde de o cerere externă variabilă. De aceea EXISTS funcția definește în mod tipic o subinterogare corelată.
Să examinăm modul în care baza de date de motor poate gestiona solicitarea în acest exemplu. În primul rând cererea externă consideră primul tabel rândul angajaților (Frolov Ofițer). Următoarea EXISTS Funcția determină dacă există un tabel de Works_on linie al cărei număr de angajați cu același număr de angajat în rândul curent în interogare exterioară, și a cărui ProjectNumber este p1. Deoarece Frolov angajat nu funcționează pe p1 proiect, interogare imbricate returnează un set gol, astfel încât existentele funcția returnează false. Astfel, angajatul Frolov care nu sunt incluse în setul de rezultate finale. Acest proces a fost supus tuturor rândurile tabelei Employee, iar apoi de ieșire din setul de rezultate finale.
Următorul exemplu arată cum se utilizează funcțiile NOT EXISTS.
În acest exemplu, există un eșantion de nume ale angajaților, al căror departament nu este situat în București.
Lista de selecție declarația SELECT din interogarea exterioară cu EXISTS funcție nu trebuie să fie neapărat în forma SELECT *, la fel ca în exemplul anterior. Puteți utiliza o formă alternativă de colum_list SELECT, în cazul în care column_list este o listă de una sau mai multe coloane într-un tabel. Ambele forme sunt echivalente deoarece existentele funcționale numai controale pentru prezența (sau absența) de rânduri din setul de rezultate. Din acest motiv, în acest caz, corect de a utiliza formularul * SELECT.
Că utilizarea unui compus sau subinterogările?
Aproape toate declarația SELECT pentru a se alătura tabel prin conexiunea operator JOIN poate înlocui un set de instrucțiuni subinterogarea și vice-versa. Design-ul SELECT folosind compusul operatorului este adesea mai convenabil pentru a citi și mai ușor de înțeles, și poate ajuta, de asemenea, baza de date Engine pentru a găsi o strategie mai eficientă pentru preluarea datelor solicitate. Dar unele sarcini sunt mai ușor de soluție prin subcereri, și altele utilizând compușii.
Avantajele subinterogarilor
Subinterogarilor va fi mai benefic pentru utilizarea în astfel de cazuri, atunci când este necesar să se calculeze valoarea totală a „on the fly“ și să-l utilizați într-o altă solicitare pentru comparație. Acest lucru este prezentat în exemplul de mai jos:
În acest exemplu, există un eșantion de numere de personal ale angajaților și datele la începutul activității lor în cadrul proiectului (EnterDate) pentru toți angajații care lucrează data de începere este data cea mai apropiată. Pentru a rezolva această problemă cu ajutorul conexiunilor nu va fi ușor, pentru că trebuie să faceți pentru a pune funcția agregată în clauza WHERE, care nu este permis. (Acest lucru poate fi realizat prin utilizarea a două cereri separate, Works_on în raport cu masa.)
conexiuni beneficii
Utilizați o conexiune în loc de subinterogările este mai favorabilă, în acele cazuri în care o listă a instrucțiunii SELECT din selecția de interogare conține coloane de la mai mult de un tabel. Acest lucru este prezentat în exemplul de mai jos: