SQL을 처음 배우거나 실무에서 활용할 때 자주 혼동되는 개념 중 하나가 뷰(View)와 테이블(Table)의 차이입니다. 두 객체 모두 SELECT 쿼리를 통해 데이터를 가져올 수 있지만, 동작 방식과 사용 목적에는 분명한 차이가 있습니다. 이 글에서는 뷰와 테이블의 기본 개념과 차이점, 그리고 언제 각각을 사용하면 좋은지를 설명합니다.

테이블(Table)의 개념

테이블은 데이터베이스에 실제 데이터를 저장하는 기본적인 객체입니다. 모든 데이터는 테이블에 물리적으로 저장되며, SELECT, INSERT, UPDATE, DELETE와 같은 SQL 명령을 통해 데이터를 조작할 수 있습니다.

예시:

CREATE TABLE employee (
    emp_id     NUMBER PRIMARY KEY,
    emp_name   VARCHAR2(100),
    dept_id    NUMBER,
    salary     NUMBER
);

이 테이블은 직원 정보를 저장하는 실제 데이터 저장소입니다.

뷰(View)의 개념

뷰는 하나 이상의 테이블을 기반으로 한 SELECT 쿼리 결과를 저장한 논리적 객체입니다. 뷰는 물리적으로 데이터를 저장하지 않고, SELECT 쿼리가 실행될 때마다 참조된 테이블에서 데이터를 가져옵니다. 즉, 뷰는 일종의 가상 테이블입니다.

예시:

CREATE VIEW high_salary_emp AS
SELECT emp_id, emp_name, salary
FROM employee
WHERE salary > 5000;

이 뷰는 salary가 5000 이상인 직원만 필터링해 보여주는 가상 테이블입니다.

뷰와 테이블의 주요 차이점

뷰는 특정 조건을 반복해서 조회할 때 유용하며, 복잡한 조인을 단순화하거나 민감 정보를 숨기는 데도 사용됩니다.

뷰는 언제 사용하면 좋을까?

• 자주 사용하는 SELECT 쿼리를 재사용할 필요가 있을 때
• 복잡한 조인이나 필터 조건을 단순화하고 싶을 때
• 특정 테이블의 일부만 사용자에게 보여주고 싶을 때
• 보안이나 권한 관리를 위해 민감 정보를 숨길 필요가 있을 때

예를 들어 외부 사용자에게 salary 컬럼을 숨기고 싶다면 다음과 같이 뷰를 생성할 수 있습니다.

CREATE VIEW public_employee AS
SELECT emp_id, emp_name, dept_id
FROM employee;

테이블이 필요한 상황은?

• 데이터를 물리적으로 저장해야 할 때
• DML(INSERT, UPDATE, DELETE)을 빈번히 수행해야 할 때
• 기본적인 데이터베이스 구조를 설계할 때

실무 팁

• 뷰를 너무 많이 계층적으로 중첩해서 만들면 오히려 성능 저하의 원인이 될 수 있습니다.
• 단순한 필터링 뷰라면 성능에 큰 영향을 주지 않지만, 여러 테이블의 조인을 포함한 복잡한 뷰는 실행 계획을 꼭 확인하는 것이 좋습니다.
• 자주 갱신되는 데이터를 대상으로 하는 경우 뷰보다는 임시 테이블 또는 머티리얼라이즈드 뷰(Materialized View)를 고려하는 것이 좋습니다.

뷰는 테이블과는 다르게 데이터 저장 목적이 아닌 가공과 재사용 목적으로 사용된다는 점이 가장 큰 차이입니다. SQL을 효율적으로 사용하기 위해서는 이 차이를 정확히 이해하고, 상황에 맞는 선택을 하는 것이 중요합니다.

#SQL #테이블 #뷰 #SQL기초 #가상테이블 #데이터베이스기초

SQL을 작성하다 보면 인라인 뷰와 테이블 조인 중 어떤 방식이 더 좋은지 고민하게 되는 경우가 많습니다. 겉으로는 같은 결과를 도출할 수 있어 보이지만, 실제로는 처리 방식이나 성능 측면에서 차이를 보일 수 있습니다. 이번 글에서는 인라인 뷰와 테이블 조인의 차이점과 실무에서 선택 기준을 어떻게 잡아야 하는지 살펴보겠습니다.

인라인 뷰란?

인라인 뷰는 FROM 절 안에 작성된 서브쿼리로, 마치 임시 테이블처럼 작동합니다. 복잡한 데이터를 미리 가공한 후, 이를 다시 외부 쿼리에서 조인하거나 필터링할 수 있게 해줍니다.

예시:

SELECT emp.empno, emp.ename, dept.dept_name
FROM (
    SELECT * FROM emp WHERE sal > 3000
) emp
JOIN dept ON emp.deptno = dept.deptno;

위 쿼리는 먼저 급여가 3000을 초과하는 직원만 추출한 다음, 해당 결과를 기반으로 부서 테이블과 조인합니다. emp는 인라인 뷰로 사용되고 있습니다.

테이블 조인 방식

테이블 조인은 일반적으로 여러 테이블을 직접 JOIN하여 필요한 데이터를 한 번에 조회하는 방식입니다. 조건이 단순하거나 중간 가공이 필요 없는 경우에 사용됩니다.

예시:

SELECT e.empno, e.ename, d.dept_name
FROM emp e
JOIN dept d ON e.deptno = d.deptno
WHERE e.sal > 3000;

이 방식은 별도의 가공 없이 바로 조건을 걸고, 조인을 수행합니다. 데이터 양이 많지 않거나 단순한 경우, 옵티마이저가 효율적으로 처리해줄 가능성이 높습니다.

어떤 차이가 있을까?

두 방식은 결과적으로 동일한 데이터를 반환할 수 있지만, 옵티마이저의 처리 방식에 따라 성능에 차이를 보일 수 있습니다. 다음은 주요 차이점입니다:

• 옵티마이저 최적화 수준: 인라인 뷰는 독립적으로 처리되는 경우가 많아 옵티마이저가 전체 쿼리의 실행 계획을 유연하게 조정하지 못하는 경우가 있습니다.
• 필터 순서 제어: 인라인 뷰 내에서는 WHERE 절이 먼저 처리되므로, 복잡한 필터링이나 가공을 먼저 수행하고 조인을 하게 됩니다.
• 읽어야 할 데이터 양: 조건에 따라 먼저 필터링을 해서 줄일 수 있다면 인라인 뷰가 더 효율적일 수 있지만, 그렇지 않으면 오히려 중복 연산이 될 수도 있습니다.

실무에서의 선택 기준

1. 필터링 우선 여부: 먼저 데이터를 가공해야만 하는 경우 → 인라인 뷰
2. 단순 조건 조합일 경우: 성능을 위해 옵티마이저에 맡기고 싶은 경우 → 테이블 조인
3. 읽어야 할 데이터 양이 많은 경우: 인라인 뷰가 오히려 느려질 수 있음 → 테이블 조인 권장
4. 복잡한 가공이나 집계를 별도로 해야 하는 경우: 인라인 뷰 활용

결론

인라인 뷰와 테이블 조인은 단순히 문법 차이가 아닌, 옵티마이저의 쿼리 처리 방식에 영향을 줍니다. 따라서 동일한 결과를 반환한다고 해서 성능도 같을 거라는 가정은 위험합니다. 실무에서는 실제 실행 계획을 확인하면서, 상황에 맞는 방식을 선택하는 것이 중요합니다.

#SQL튜닝 #인라인뷰 #테이블조인 #SQL성능 #서브쿼리 #오라클쿼리팁 #오라클튜닝

ORDER BY 절은 SQL 쿼리에서 결과를 정렬하는 데 사용되며, 사용자에게 보기 좋은 데이터를 제공할 수 있습니다. 하지만 무심코 사용하는 ORDER BY가 성능에 큰 영향을 미칠 수 있다는 사실은 자주 간과됩니다.

1. ORDER BY는 왜 비용이 클까?

ORDER BY는 단순한 결과 필터링이 아니라, 전체 결과 집합을 대상으로 정렬 연산을 수행합니다. 이 정렬 과정은 메모리 또는 디스크 정렬을 수반하며, 다음과 같은 경우 성능 병목을 일으킬 수 있습니다.

• 정렬 대상 컬럼에 인덱스가 없을 경우
• 정렬 대상이 조인 결과나 서브쿼리 결과일 경우
• 정렬 대상 레코드가 대량일 경우

특히 테이블 전체 스캔 후 정렬이 필요한 경우, 쿼리 성능 저하가 매우 두드러지게 나타납니다.

2. 실행 계획에서의 정렬 확인

Oracle에서 쿼리 실행 계획을 보면 정렬 연산은 다음과 같이 나타납니다:

SORT ORDER BY

이 단계가 포함되어 있다면, 정렬에 따른 자원 사용이 발생했음을 의미합니다. 예를 들어 다음과 같은 쿼리를 보겠습니다.

SELECT name, salary
FROM employee
ORDER BY salary DESC;

인덱스가 없다면, 전 직원 데이터를 불러온 뒤 정렬 작업이 추가로 수행됩니다. 반면, salary에 인덱스가 존재하면 Oracle은 그 인덱스를 활용해 정렬 작업 없이 데이터를 바로 가져올 수 있습니다.

3. 정렬 성능을 개선하는 팁

• ORDER BY 대상 컬럼에 인덱스를 생성하면 성능 향상 가능성이 높습니다.
• 불필요한 정렬을 제거할 수 있다면 제거하세요. 애플리케이션에서 정렬하는 방식도 고려해볼 수 있습니다.
• LIMIT(FETCH FIRST n ROWS)와 함께 쓰는 경우, 인덱스를 활용하면 훨씬 효율적입니다.

예를 들어:

SELECT name
FROM employee
ORDER BY salary DESC
FETCH FIRST 10 ROWS ONLY;

이 쿼리는 상위 몇 개만 필요한 상황인데, 인덱스를 타면 훨씬 빠르게 처리됩니다.

4. 결론

ORDER BY는 눈에 보이지 않게 쿼리 성능을 잡아먹는 연산입니다. 특히 대용량 데이터 처리에서 정렬 연산은 치명적일 수 있으므로, 인덱스 구조와 실행 계획을 고려한 설계가 필요합니다.

정렬이 필요한 이유가 분명한지, 그리고 그것이 최적화된 형태로 실행되는지를 항상 점검하는 습관이 중요합니다.

#SQL기초 #ORDERBY #정렬성능 #실행계획 #쿼리최적화 #인덱스활용

IN과 EXISTS는 둘 다 서브쿼리를 사용하는 조건절로, 결과적으로 같은 데이터를 반환할 수 있지만 내부 동작 방식과 성능 차이로 인해 상황에 따라 적절한 선택이 필요합니다.

1. IN 절과 EXISTS 절의 기본 사용법

IN 절 예시:

SELECT name
FROM employee
WHERE department_id IN (
    SELECT id
    FROM department
    WHERE region = '서울'
);

EXISTS 절 예시:

SELECT name
FROM employee e
WHERE EXISTS (
    SELECT 1
    FROM department d
    WHERE d.id = e.department_id
    AND d.region = '서울'
);

위 두 쿼리는 동일한 결과를 반환하지만, 내부적으로 처리하는 방식은 전혀 다릅니다.

2. 내부 동작 방식의 차이

• IN은 서브쿼리 결과를 메모리에 모두 로드하고, 메인 쿼리의 비교 값을 그 목록과 매칭합니다.
• EXISTS는 서브쿼리가 조건을 만족하는 레코드가 하나라도 존재하는지 확인하는 방식으로, 참(True)이 되는 순간 바로 반환됩니다.

즉, EXISTS는 조건을 만족하는 레코드를 찾자마자 종료되는 반면, IN은 전체 리스트를 끝까지 확인하는 구조입니다.

3. 성능 차이 – 언제 어느 걸 쓰는 게 좋을까?

• 서브쿼리의 결과가 매우 많은 경우 → EXISTS가 더 유리한 경우가 많습니다.
• 서브쿼리의 결과가 작고 명확한 리스트라면 IN이 더 직관적이고 성능상 문제가 없습니다.
• 서브쿼리에 NULL이 포함될 가능성이 있다면 EXISTS를 쓰는 것이 안전합니다.

4. 실무 팁

• Oracle에서는 IN과 EXISTS의 성능 차이가 DB 버전이나 옵티마이저 설정에 따라 달라질 수 있으므로, 항상 실제 실행 계획(EXPLAIN PLAN)을 통해 비교하는 것이 가장 정확합니다.
• WHERE 절 내 조건의 순서가 성능에 미치는 영향도 함께 고려해 조합적으로 테스트하는 습관이 필요합니다.

IN과 EXISTS는 비슷해 보이지만 그 사용 방식과 성능은 꽤 다릅니다. 단순히 동작만 이해할 것이 아니라, 각 조건의 구조와 서브쿼리 특성에 맞춰 쿼리를 작성해야 최적화된 결과를 얻을 수 있습니다.

#SQL기초 #IN절 #EXISTS절 #SQL서브쿼리 #SQL성능비교 #쿼리최적화

LIKE 연산자는 SQL에서 문자열 패턴을 검색할 때 자주 사용되는 조건입니다. 특히 % 와 _ 와 같은 와일드카드(wildcard) 문자를 적절히 활용하면 유연한 문자열 검색이 가능합니다. 그러나 이러한 와일드카드의 의미를 명확히 이해하지 못하면, 원하지 않는 결과를 얻을 수 있습니다.

1. 와일드카드 종류와 의미

LIKE 조건에서 사용 가능한 와일드카드는 다음과 같습니다:

• %: 길이에 상관없이 모든 문자열을 의미합니다. 0자 이상.
• _: 임의의 한 글자를 의미합니다.

예시:

SELECT * FROM employee
WHERE name LIKE '김%';

→ 이름이 '김'으로 시작하는 모든 직원 검색

SELECT * FROM employee
WHERE name LIKE '_현우';

→ 앞에 어떤 한 글자가 있고, 뒤에 '현우'가 오는 이름 검색 (예: '이현우', '박현우')

2. 실제 사용 예시

다음은 %와 _를 함께 사용하는 예시입니다:

SELECT * FROM product
WHERE code LIKE 'A__%';

→ 'A'로 시작하고, 그 뒤에 정확히 두 글자가 있으며, 그 이후에 문자열이 이어지는 상품 코드 검색

3. ESCAPE 문자를 활용한 예외 처리

만약 검색하려는 문자열에 %나 _가 포함되어 있다면, 이를 문자 그대로 검색하기 위해 ESCAPE 절을 사용할 수 있습니다.

SELECT * FROM memo
WHERE content LIKE '%!%%' ESCAPE '!';

→ 메모 내용에 실제 % 문자가 포함된 항목 검색

4. 주의할 점

• %는 넓은 범위의 검색을 유도하기 때문에, 인덱스를 잘 타지 않습니다.
• 문자열 앞에 %가 오면 인덱스 미사용이 될 가능성이 높습니다.
• 성능 최적화가 중요한 상황에서는 가급적 LIKE 조건 대신 FULLTEXT 검색이나 정규표현식 등을 사용하는 것이 유리할 수 있습니다.

SQL에서 LIKE 연산자를 단순히 ‘포함 조건’ 정도로만 이해하고 사용하는 경우가 많습니다. 하지만 와일드카드의 특성과 인덱스 영향까지 고려하면 보다 정확하고 성능 좋은 쿼리를 작성할 수 있습니다.

#SQL기초 #LIKE연산자 #SQL와일드카드 #문자열검색 #SQL쿼리팁

SQL에서 복잡한 쿼리를 작성할 때, 서브쿼리로만 해결하기 어려운 경우가 많습니다. 이럴 때 CTE (Common Table Expressions), 즉 WITH 구문을 사용하면 쿼리의 가독성과 유지보수를 크게 향상시킬 수 있습니다.

CTE의 기본 구조

CTE는 쿼리 상단에 WITH 절로 정의하며, 마치 임시 테이블처럼 재사용할 수 있습니다. 기본 구조는 다음과 같습니다.

WITH cte_name AS (
    SELECT ... FROM ...
)
SELECT * FROM cte_name;

첫 번째 부분에서 cte_name 이라는 이름의 CTE를 정의하고, 이후 메인 쿼리에서 이를 참조합니다.

CTE 사용의 장점

1. 가독성 향상
   복잡한 로직을 여러 단계로 나누어 각각의 CTE로 정의하면, 전체 쿼리의 흐름을 한눈에 파악할 수 있어 디버깅과 협업에 유리합니다.

2. 재사용성
   한 번 정의한 CTE를 메인 쿼리 내에서 여러 번 사용할 수 있으므로, 같은 로직을 반복 작성할 필요가 없습니다.

3. 재귀 쿼리 작성
   CTE는 재귀적 호출을 지원하여, 계층적 데이터(예: 조직도나 카테고리 구조)를 쉽게 처리할 수 있습니다.

실무 예시: 고객별 최근 주문 내역과 누적 주문 수

아래 예시는 고객 테이블과 주문 테이블을 기반으로, 각 고객의 최근 주문 날짜와 누적 주문 수를 CTE로 먼저 계산한 후, 이를 메인 쿼리에서 결합하는 예시입니다.

WITH order_summary AS (
    SELECT customer_id,
           COUNT(*) AS total_orders,
           MAX(order_date) AS last_order_date
    FROM orders
    GROUP BY customer_id
)
SELECT c.customer_id, c.name,
       o.total_orders, o.last_order_date
FROM customers c
LEFT JOIN order_summary o ON c.customer_id = o.customer_id;

이 쿼리는 주문 집계 로직을 별도로 분리하여, 고객 테이블과 조인할 때 단순하게 결과를 얻을 수 있습니다.

마무리

CTE(Common Table Expressions)는 복잡한 쿼리를 구조화하고 가독성을 높이는 데 매우 유용한 도구입니다. 서브쿼리로 얽힌 코드를 단순화하고, 재사용 가능한 형태로 구현할 수 있으므로, 실무에서 적극 활용하는 것이 좋습니다.

#SQL #CTE #WITH구문 #공통테이블표현 #쿼리최적화 #SQL기초 #실무팁 #데이터베이스

SQL에서 조건에 따라 다른 값을 출력해야 할 때 CASE WHEN 구문을 사용합니다. 이는 프로그래밍 언어에서의 if-else처럼 조건 분기를 처리할 수 있도록 도와주며, 특히 SELECT 문 안에서 동적으로 컬럼 값을 제어할 때 자주 사용됩니다.

CASE WHEN의 기본 구조

CASE 구문은 다음과 같은 형식으로 작성합니다.

SELECT 컬럼명,
       CASE
           WHEN 조건1 THEN 결과1
           WHEN 조건2 THEN 결과2
           ELSE 기본값
       END AS 별칭
FROM 테이블명;

조건이 참인 첫 번째 WHEN 절이 실행되고, 해당 조건이 모두 거짓인 경우 ELSE 절의 값이 반환됩니다.

실무 예시: 고객 등급 분류

예를 들어, 고객의 구매 금액을 기준으로 등급을 나누는 쿼리는 다음과 같습니다.

SELECT 고객명,
       구매금액,
       CASE
           WHEN 구매금액 >= 100000 THEN 'VIP'
           WHEN 구매금액 >= 50000 THEN '우수'
           ELSE '일반'
       END AS 고객등급
FROM 고객테이블;

이 쿼리를 사용하면 금액에 따라 각 고객이 어떤 등급인지 자동으로 분류할 수 있습니다.

GROUP BY, ORDER BY와 함께 사용

CASE 문은 GROUP BY나 ORDER BY와 함께 쓰일 때도 강력한 유연성을 발휘합니다. 예를 들어, 지역별로 '수도권'과 '비수도권'을 나눠 집계하고 싶을 때는 다음과 같이 활용합니다.

SELECT
    CASE
        WHEN 지역 IN ('서울', '경기', '인천') THEN '수도권'
        ELSE '비수도권'
    END AS 권역,
    COUNT(*) AS 고객수
FROM 고객테이블
GROUP BY
    CASE
        WHEN 지역 IN ('서울', '경기', '인천') THEN '수도권'
        ELSE '비수도권'
    END;

주의할 점

• CASE 구문은 WHERE 절에서 직접 사용할 수 없습니다. 조건 분기가 필요한 경우엔 서브쿼리나 CTE(Common Table Expression)로 처리하는 것이 일반적입니다.
• 조건 순서가 중요합니다. 먼저 작성된 WHEN 조건부터 평가되므로, 조건이 중첩될 수 있는 경우에는 우선순위를 고려해야 합니다.

마무리

CASE WHEN 구문은 SQL에서 데이터를 조건에 따라 분기해 보여줄 때 매우 유용한 도구입니다. 특히 복잡한 조건을 단일 컬럼 안에서 처리할 수 있어 가독성과 유지보수 측면에서도 장점이 많습니다. 실무에서도 흔히 사용되는 만큼, 다양한 상황에 적용해보며 익숙해지는 것이 중요합니다.

#SQL #CASE문 #조건분기 #SQL기초 #WHENTHEN #쿼리작성팁 #SELECT문 #데이터분석

SQL에서 자주 사용하는 집계 함수 중 하나인 COUNT()는 단순히 행의 수를 세는 데에 유용합니다. 하지만 COUNT(*)와 COUNT(컬럼명)은 비슷해 보이지만 실제 의미와 동작 방식에서 중요한 차이를 가지고 있습니다.

COUNT(*)는 모든 행을 센다

COUNT(*)는 해당 테이블에서 NULL을 포함한 모든 행의 개수를 셉니다. 이는 테이블에 존재하는 전체 레코드 수를 파악하고자 할 때 사용됩니다.

예시:

SELECT COUNT(*) FROM employees;

이 쿼리는 employees 테이블의 총 행 수를 반환합니다. 특정 컬럼에 NULL이 있든 없든 관계없이 전체 행 수를 기준으로 계산합니다.

COUNT(컬럼명)는 NULL을 제외한다

반면 COUNT(컬럼명)은 해당 컬럼에서 NULL이 아닌 값의 개수만 셉니다. 즉, 어떤 컬럼의 값이 얼마나 채워져 있는지, 즉 실제 데이터가 있는 레코드 수를 알고 싶을 때 유용합니다.

예시:

SELECT COUNT(department_id) FROM employees;

이 쿼리는 department_id 컬럼의 값이 NULL이 아닌 행의 개수를 반환합니다. 만약 부서가 배정되지 않은 사원이 있다면 그 행은 집계에서 제외됩니다.

실무에서의 활용 팁

• 데이터 완전성 검증 시에는 COUNT(컬럼명)을 사용하여 누락된 값이 있는지 파악합니다.
• 전체 행 수가 필요한 로깅, 페이징 처리 등에서는 COUNT(*)을 사용하는 것이 적절합니다.
• COUNT(DISTINCT 컬럼명)처럼 고유한 값의 개수를 세는 방식과도 구분하여 사용해야 합니다.

결론

COUNT(*)과 COUNT(컬럼명)은 비슷해 보이지만 전혀 다른 결과를 가져올 수 있으므로, 목적에 따라 정확히 구분하여 사용하는 것이 중요합니다. 특히 실무에서 NULL 값이 얼마나 존재하는지를 파악할 때 이 차이를 알고 있으면 보다 정확한 데이터 분석이 가능합니다.

#SQL #COUNT #집계함수 #기초정리 #데이터베이스 #NULL #쿼리

SQL에서 데이터를 합치기 위해 가장 먼저 떠오르는 키워드는 JOIN입니다. 하지만 모든 상황에서 JOIN이 꼭 필요한 것은 아닙니다. 실무에서는 JOIN을 쓰기 복잡하거나 성능상 불리할 때, 서브쿼리(Subquery)를 이용해 문제를 해결하기도 합니다. 이번 글에서는 JOIN 없이 서브쿼리만으로 해결할 수 있는 3가지 실무 상황을 소개합니다.

1. 특정 조건에 해당하는 값만 가져올 때

예를 들어 각 사원의 부서 이름을 출력하고 싶은데, 특정 부서만 필터링하고 싶다면 JOIN 없이도 다음과 같이 서브쿼리로 처리할 수 있습니다.

SELECT emp_name,
       (SELECT dept_name
        FROM department d
        WHERE d.dept_id = e.dept_id)
       AS dept_name
FROM employee e
WHERE e.dept_id IN (10, 20);

JOIN을 사용하지 않고도 서브쿼리로 필요한 부서명을 함께 출력할 수 있습니다.

2. 조건 비교를 위해 필요한 보조 데이터를 가져올 때

각 제품의 가격이 전체 평균보다 높은 제품만 찾고 싶다면, 아래와 같이 서브쿼리를 WHERE 절에 활용할 수 있습니다.

SELECT product_name, price
FROM product
WHERE price > (SELECT AVG(price) FROM product);

이처럼 전체 집계 결과와 비교할 때도 서브쿼리를 사용하면 JOIN 없이 해결할 수 있습니다.

3. 최근 거래 내역 등 특정 조건의 1건만 가져올 때

각 고객의 최근 주문 내역을 보고 싶다면, 관련 테이블을 JOIN하기보다 상관 서브쿼리를 사용할 수 있습니다.

SELECT c.customer_id,
       (SELECT order_date
        FROM orders o
        WHERE o.customer_id = c.customer_id
        ORDER BY order_date DESC
        FETCH FIRST 1 ROW ONLY)
       AS latest_order
FROM customer c;

이 방식은 고객 수가 많아도 간결하고 효율적인 쿼리를 작성할 수 있게 해줍니다.

JOIN은 강력한 도구지만, 서브쿼리는 구조를 단순화하거나 불필요한 조인을 줄이는 데 유용하게 쓰일 수 있습니다. 실무에서는 복잡한 조인보다 오히려 서브쿼리로 명확하게 표현하는 것이 유지보수나 성능 측면에서 더 나은 선택이 되는 경우도 많습니다.

#SQL #서브쿼리 #JOIN #실무팁 #쿼리작성 #DB초보 #SQL기초

SQL에서 중복된 값을 제거하기 위해 DISTINCT를 사용하고, 데이터를 그룹화하기 위해 GROUP BY를 사용합니다. 하지만 때로는 두 문장이 같은 결과를 반환하기도 하여, 어떤 걸 써야 할지 혼란스러울 수 있습니다. 이 글에서는 두 구문의 차이를 명확하게 정리합니다.

DISTINCT: 단순히 중복된 행을 제거

DISTINCT는 SELECT 절에서 중복된 행을 제거하는 용도로 사용됩니다. 특정 컬럼 또는 여러 컬럼 조합이 중복일 경우, 하나만 남기고 제거합니다.

예시:

SELECT DISTINCT dept_id 
FROM employees;

→ 부서 ID가 중복되는 경우 하나만 표시됩니다.

여러 컬럼을 기준으로도 중복 제거가 가능합니다:

SELECT DISTINCT dept_id, job 
FROM employees;

→ 부서 ID와 직책 조합이 동일한 경우, 하나만 남깁니다.

GROUP BY: 데이터를 그룹으로 묶은 후 집계

GROUP BY는 데이터를 그룹화한 뒤, 집계 함수(SUM, COUNT 등)를 함께 사용할 때 주로 사용됩니다. 단순히 중복 제거가 목적이라면 DISTINCT가 더 적절하지만, 그룹별 통계가 필요하다면 GROUP BY를 사용해야 합니다.

예시:

SELECT dept_id, COUNT(*) 
FROM employees
GROUP BY dept_id;

→ 부서별로 몇 명의 직원이 있는지를 보여줍니다.

만약 집계 함수 없이 GROUP BY만 사용한다면 DISTINCT와 유사한 결과가 나오지만, 문장의 의미는 다릅니다.

예시:

SELECT dept_id 
FROM employees 
GROUP BY dept_id;

→ SELECT DISTINCT dept_id FROM employees;와 결과는 같지만, 의미상 그룹화입니다.

정리

실무 팁: 결과만 보고 두 문장을 혼동하면 안 됩니다. 왜 이 구문을 쓰는지, 목적에 따라 구문을 선택하세요.

#SQL #DISTINCT #GROUPBY #중복제거 #집계함수 #기초정리 #실무팁 #데이터분석