DISTINCT vs GROUP BY – 결과는 같아도 목적은 다르다

Posted by heoncode
2025. 4. 11. 11:20 SQL 기초 정리
반응형

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

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

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

예시:

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;와 결과는 같지만, 의미상 그룹화입니다.


정리

목적 사용 구문
단순 중복 제거 DISTINCT
집계 또는 그룹 통계 GROUP BY

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


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

반응형

WHERE 절과 HAVING 절, 헷갈리는 이유와 실무 기준 정리

Posted by heoncode
2025. 4. 11. 08:41 SQL 기초 정리
반응형

SQL에서 조건을 설정할 수 있는 절은 대표적으로 WHEREHAVING이 있습니다. 둘 다 데이터를 필터링하는 기능이지만, 사용하는 시점과 용도에는 분명한 차이가 있습니다. 실무에서도 종종 이 둘을 혼용하거나, 쿼리가 잘못 동작하는 원인이 되기도 합니다.

WHERE 절: 집계 전 데이터를 필터링

WHERE 절은 그룹화나 집계가 수행되기 전에 데이터를 필터링합니다. 즉, 원본 테이블에서 조건을 걸고 필요한 행만 남긴 후에 GROUP BY, SUM, AVG 등의 집계 함수가 동작합니다.

예시:

SELECT dept_id, COUNT(*) 
FROM employees
WHERE job = 'MANAGER'
GROUP BY dept_id;

→ 여기서 WHERE은 "직책이 MANAGER인 직원"만 대상으로 그룹화합니다.

HAVING 절: 집계 이후 그룹 필터링

HAVING 절은 GROUP BY 이후 집계된 결과에 조건을 거는 데 사용합니다. WHERE과 달리 집계 함수(COUNT, SUM, 등)를 사용할 수 있습니다.

예시:

SELECT dept_id, COUNT(*) AS cnt
FROM employees
GROUP BY dept_id
HAVING COUNT(*) >= 5;

→ 모든 부서를 그룹화한 후, 직원 수가 5명 이상인 부서만 결과로 출력됩니다.

둘 다 쓰는 경우

두 절을 함께 쓰는 것도 가능합니다. 이때는 WHERE이 먼저, HAVING이 나중에 적용됩니다.

SELECT dept_id, COUNT(*) 
FROM employees
WHERE job = 'MANAGER'
GROUP BY dept_id
HAVING COUNT(*) >= 2;

→ MANAGER만 대상으로 부서별 그룹을 만들고, 그중에서 2명 이상인 부서만 필터링합니다.


실무 팁으로 기억하면 좋습니다:

  • WHERE은 개별 행을 필터링
  • HAVING은 집계 결과를 필터링

이 원칙만 기억하면 두 조건절을 헷갈릴 일이 줄어듭니다.


#SQL #WHERE절 #HAVING절 #조건절 #GROUPBY #집계함수 #기초정리 #실무팁

반응형

LEFT JOIN 결과가 예상과 다를 때? 누락된 데이터의 진짜 원인

Posted by heoncode
2025. 4. 11. 00:38 SQL 기초 정리
반응형

SQL에서 LEFT JOIN왼쪽 테이블의 모든 데이터를 기준으로 오른쪽 테이블과 연결해주는 기능입니다. 하지만 실무에서는 종종 LEFT JOIN을 썼는데도 결과가 예상보다 적게 나오는 일이 발생합니다. 이 글에서는 그런 상황에서 확인해야 할 3가지 핵심 원인을 소개합니다.

1. WHERE 절 조건이 JOIN 결과를 제한한다

아래 쿼리를 살펴봅시다:

SELECT *
FROM employees e
LEFT JOIN departments d ON e.dept_id = d.id
WHERE d.location = 'SEOUL';

의도는 모든 직원 정보를 보고 싶은 것인데, 이 쿼리는 d.location이 NULL인 직원(=부서가 없는 직원)은 제외됩니다. 이는 WHERE 절이 조인 이후에 적용되기 때문입니다.

→ 해결책은 조건을 JOIN 안에 넣는 것입니다:

SELECT *
FROM employees e
LEFT JOIN departments d ON e.dept_id = d.id AND d.location = 'SEOUL';

이렇게 하면 부서가 없는 직원도 빠지지 않습니다.

2. JOIN 조건이 누락되거나 잘못되었다

SELECT *
FROM employees e
LEFT JOIN departments d ON e.name = d.name;

이런 식으로 정확한 조인 조건 없이 컬럼 이름만 같은 걸 기준으로 조인하면 원하지 않는 결과가 나옵니다. 항상 기본키-외래키 관계 또는 고유한 값을 기준으로 조인해야 합니다.

3. 중첩 JOIN과 서브쿼리에서 발생하는 필터링

복잡한 쿼리일수록 LEFT JOIN이 서브쿼리 내부에 있거나 INNER JOIN과 함께 쓰이면서 무의식적으로 결과가 줄어들 수 있습니다. 쿼리 구조를 항상 시각화하면서 데이터 흐름을 따져보는 습관이 필요합니다.


LEFT JOIN은 단순한 듯 보여도 실무에서는 자주 함정에 빠지는 구간입니다. 특히 WHERE 절의 위치나 조인 조건에 따라 결과가 확 달라질 수 있으니 항상 주의 깊게 쿼리를 작성해야 합니다.


#SQL #JOIN #LEFTJOIN #외부조인 #누락 #쿼리디버깅 #기초정리 #실무팁

반응형