I SQL er en korrelert underspørring en underspørring som refererer til en kolonne fra den ytre spørringen. Underspørringen utføres gjentatte ganger for hver rad i den ytre spørringen, ved å bruke verdiene fra gjeldende rad for å utføre underspørringen. Resultatet av underspørringen brukes deretter i evalueringen av den ytre spørringen.

Korrelerte underspørringer brukes for rad-for-rad-behandling. Hver underspørring utføres én gang for hver rad i den ytre spørringen.

En korrelert underspørring blir evaluert én gang for hver rad som behandles av den overordnede setningen. Overordnet uttalelse kan være en PLUKKE UT , OPPDATER , eller SLETT uttalelse.

Syntaks:

VELG kolonne1, kolonne2, ….

FRA bord1 ytre

WHERE kolonne1 operator

(VELG kolonne1, kolonne2

FRA tabell 2

WHERE uttr1 =

ytre.uttr2);

En korrelert underspørring er én måte å lese hver rad i en tabell og sammenligne verdier i hver rad med relaterte data. Den brukes når en underspørring må returnere et annet resultat eller sett med resultater for hver kandidatrad som vurderes av hovedspørringen. Med andre ord kan du bruke en korrelert underspørring til å svare på et flerdelt spørsmål hvis svar avhenger av verdien i hver rad som behandles av den overordnede setningen.

Nestede underspørringer versus korrelerte underspørringer

Med en normal nestet underspørring, den indre PLUKKE UT spørringen kjøres først og kjøres én gang, og returnerer verdier som skal brukes av hovedspørringen. En korrelert underspørring kjøres imidlertid én gang for hver kandidatrad som vurderes av den ytre spørringen. Med andre ord er den indre spørringen drevet av den ytre spørringen.

MERK: Du kan også bruke NOEN og ALLE operatør i en korrelert underspørring. EKSEMPEL på korrelerte underspørringer: Finn alle de ansatte som tjener mer enn gjennomsnittslønnen i sin avdeling.

Spørsmål:

SELECT last_name, salary, department_id  FROM employees outer  WHERE salary>(VELG AVG(lønn) FRA ansatte HVOR avdeling_id = ytre.avdeling_id gruppe etter avdelings_id);>

Annen bruk av korrelasjon er i OPPDATER og SLETT

KORLERERT OPPDATERING

UPDATE table1 alias1  SET column = (SELECT expression   FROM table2 alias2  WHERE alias1.column =  alias2.column);>

Bruk en korrelert underspørring for å oppdatere rader i én tabell basert på rader fra en annen tabell.

KORLERERT SLETT

DELETE FROM table1 alias1  WHERE column1 operator  (SELECT expression  FROM table2 alias2  WHERE alias1.column = alias2.column);>

Bruk en korrelert underspørring for å slette rader i én tabell basert på radene fra en annen tabell.

java initialiseringsarray

Bruk av EXISTS-operatøren

EXISTS-operatoren tester for eksistensen av rader i resultatsettet til underspørringen. Hvis en underspørringsradverdi blir funnet, blir betingelsen flagget EKTE og søket fortsetter ikke i den indre spørringen, og hvis den ikke blir funnet, blir betingelsen flagget FALSK og søket fortsetter i den indre spørringen.
EKSEMPEL på bruk av EXIST-operatoren:
Finn ansatte som har minst én person som rapporterer til seg.

Spørsmål:

SELECT employee_id, last_name, job_id, department_id FROM employees outer WHERE EXISTS ( SELECT ’X’ FROM employees WHERE manager_id = outer.employee_id);>

OUTPUT:

EKSEMPEL på bruk av NOT EXIST-operatoren
Finn alle avdelinger som ikke har noen ansatte.

Spørsmål:

SELECT department_id, department_name FROM departments d WHERE NOT EXISTS (SELECT ’X’ FROM employees WHERE department_id = d.department_id);>

OUTPUT:

Vanlige spørsmål om SQL-korrelerte underspørringer – vanlige spørsmål

Hva er forskjellen mellom korrelerte underspørringer og vanlige underspørringer?

Vanlige underspørringer (ikke-korrelerte) er uavhengige av den ytre spørringen og evalueres bare én gang før hovedspørringen kjøres. Derimot er korrelerte underspørringer avhengige av den ytre spørringen og utføres for hver rad i hovedspørringen.

Når bør jeg bruke korrelerte underspørringer?

Korrelerte underspørringer er nyttige når du trenger å filtrere resultatet av den ytre spørringen basert på en tilstand som krever referanseverdier fra selve den ytre spørringen. De brukes ofte i scenarier der tilstanden er avhengig av data fra relaterte tabeller.