sqld

서브쿼리

자격증원톱 2026. 2. 24. 16:31
반응형

서브쿼리

반응형

A. 서브쿼리 요약 (핵심 개념 + 연관 서브쿼리)

1) 서브쿼리(Subquery) 한 줄 정의

  • 쿼리 안에 들어가는 또 다른 쿼리입니다.
  • “먼저 작은 쿼리로 기준/목록/값을 만들고 → 메인쿼리가 그걸 이용해 조회/수정”하는 구조입니다.

2) 연관 서브쿼리(Correlated Subquery)란?

이미지 핵심:

  • 메인쿼리의 ‘각 행(row)’마다 서브쿼리가 다시 실행됩니다.
  • 서브쿼리가 메인쿼리의 컬럼을 참조합니다. (예: E1.DEPTNO를 서브쿼리에서 사용)
  • 그래서 일반(비연관) 서브쿼리보다 느릴 수 있음(행마다 반복 실행되기 때문).

3) 연관 서브쿼리 예시 1: “자기 부서 평균보다 급여가 높은 직원”

의미:

  • 직원 한 명(E1)을 기준으로,
  • “E1이 속한 부서의 평균 급여”를 다시 계산해서,
  • E1의 급여가 그 평균보다 큰지 비교합니다.

예시 SQL(교재 흐름 그대로):

SELECT ENAME, SAL, DEPTNO
FROM EMP E1
WHERE SAL > (
SELECT AVG(SAL)
FROM EMP E2
WHERE E1.DEPTNO = E2.DEPTNO
);
 
 
 

쉽게 말하면

  • “각 직원이 속한 반의 평균 점수”를 구해서,
  • “내 점수가 우리 반 평균보다 높냐?”를 보는 것과 같습니다.

4) 연관 서브쿼리 예시 2: “각 부서에서 가장 최근에 고용된 직원”

의미:

  • 직원 한 명(E1)을 기준으로,
  • “E1 부서에서 가장 최근 입사일(MAX(HIREDATE))”을 찾아서,
  • 그 날짜와 E1의 입사일이 같으면 뽑습니다.

예시 SQL:

SELECT ENAME, HIREDATE, DEPTNO
FROM EMP E1
WHERE HIREDATE = (
SELECT MAX(HIREDATE)
FROM EMP E2
WHERE E1.DEPTNO = E2.DEPTNO
);
 
 
 

결과 느낌

  • 부서 10 → 그 부서에서 가장 최근 입사한 1명
  • 부서 20 → 그 부서에서 가장 최근 입사한 1명
  • 부서 30 → 그 부서에서 가장 최근 입사한 1명
    이런 식으로 “부서별 대표 1명”을 뽑는 패턴입니다.

5) 같은 문제를 다른 방식으로도 풀 수 있다

이미지에서도 “GROUP BY로 부서별 MAX(HIREDATE) 뽑을 수도 있다”는 흐름이 나옵니다.

예:

SELECT DEPTNO, MAX(HIREDATE)
FROM EMP
GROUP BY DEPTNO;
 
 
 

다만 이건 “부서별 최신 날짜”만 나오고, “직원 이름까지 같이” 보려면 조인/서브쿼리/윈도우 함수 등 추가가 필요합니다.

B. 뷰(View) 요약 (뷰 vs 테이블, Materialized View 포함)

1) 뷰(View)란?

  • SELECT 결과를 ‘가상 테이블’처럼 저장해 두는 것입니다.
  • 실제 데이터를 복사해 저장하는 게 아니라, **SELECT 문 자체(정의)**를 저장하는 개념에 가깝습니다.

예시(교재 흐름):

  • “부서 위치(LOC)가 CHICAGO인 부서에 속한 직원 목록”을 자주 본다면,
    매번 복잡한 조인을 치지 말고 뷰로 만들어 둡니다.
CREATE VIEW EMP_DEPT_VIEW AS
SELECT E.ENAME, E.JOB, D.DNAME, D.LOC
FROM EMP E
JOIN DEPT D ON E.DEPTNO = D.DEPTNO
WHERE D.LOC = 'CHICAGO';
 
 
 

이후에는:

SELECT * FROM EMP_DEPT_VIEW;
 
 
 

처럼 테이블 조회하듯 쓰면 됩니다.

2) 뷰를 쓰는 이유(장점)

이미지 핵심을 쉬운 말로 정리하면:

  • 복잡한 쿼리 단순화: 조인/조건이 긴 쿼리를 이름으로 저장해 재사용
  • 보안/권한 제어: 원본 테이블 전체를 주지 않고, 필요한 컬럼/행만 보여주기
  • 일관성: 여러 사람이 같은 기준으로 조회(“정의가 한 곳에 있음”)

3) 뷰(View) vs 테이블(Table) 차이

  • 테이블: 데이터 자체를 저장
  • 뷰: “조회 정의(SELECT)”를 저장 → 조회할 때마다 원본에서 다시 읽어 계산

그래서 뷰는 보통:

  • 저장공간 부담이 적고,
  • 항상 최신 원본을 기준으로 결과가 나옴(원본이 바뀌면 뷰 결과도 바뀜)

4) Materialized View(머티리얼라이즈드 뷰)

이미지 핵심:

  • 일반 뷰는 “정의만 저장”이라 조회할 때 계산 부담이 있을 수 있음
  • Materialized View는 결과 데이터를 실제로 저장해둡니다(캐시처럼).

장점:

  • 조회가 빠를 수 있음(이미 결과가 저장되어 있으니까)

단점:

  • 원본이 바뀌어도 바로 반영되지 않을 수 있음 → “갱신(Refresh)” 개념이 필요

한 줄 비유

  • View: “레시피만 적어둔 것(요리할 때마다 새로 만듦)”
  • Materialized View: “미리 만들어 냉장고에 넣어둔 완성 요리(꺼내 먹기 빠름, 대신 신선도 관리 필요)”

정리(시험용 한 문장 요약)

  • 서브쿼리: 쿼리 안의 쿼리로 “기준값/목록/조건”을 만들어 메인쿼리가 활용한다.
  • 연관 서브쿼리: 메인쿼리의 각 행과 연결되어 행마다 서브쿼리가 반복 실행된다(부서 평균 비교, 부서별 최신 입사자 등).
  • 뷰(View): SELECT 결과를 가상 테이블처럼 쓰는 재사용/보안/단순화 도구(정의 저장).
  • Materialized View: 뷰 결과를 실제로 저장해 조회 성능을 높이지만 갱신 관리가 필요하다.

 

반응형