02월 26일자로 빅쿼리에 GROUP BY ALL 문법이 추가됐다. 기존에는 쿼리를 묶고 싶으면 GROUP BY에 컬럼을 지정해줘야 했는데, GROUP BY ALL 문법의 추가로 이제 빅쿼리가 SELECT 절에서 그룹화할 키를 알아서 묶게 할 수 있게 됐다.

묶는 조건은 단순한데, 집계 함수나 윈도우 함수 외 몇 가지 공식 문서에서 지정한 불가 형태 제외하고 나머지 컬럼은 다 그GROUP BY에 포함시키는 식이다. 이 때 상기 조건들을 제외하고 난 후, 남은 SELECT 항목 중 그룹화 불가한 유형이 있는 경우 오류가 발생한다. 

다음 예제에서 쿼리는 first_name과 last_name 기준으로 그룹화된다. total_points는 집계 함수 값이므로 제외됐다.

WITH PlayerStats AS (
  SELECT 'Adams' as LastName, 'Noam' as FirstName, 3 as PointsScored UNION ALL
  SELECT 'Buchanan', 'Jie', 0 UNION ALL
  SELECT 'Coolidge', 'Kiran', 1 UNION ALL
  SELECT 'Adams', 'Noam', 4 UNION ALL
  SELECT 'Buchanan', 'Jie', 13)
  
SELECT SUM(PointsScored) AS total_points
  		, FirstName AS first_name
  		, LastName AS last_name
FROM PlayerStats
GROUP BY ALL;

/*--------------+------------+-----------+
 | total_points | first_name | last_name |
 +--------------+------------+-----------+
 | 7            | Noam       | Adams     |
 | 13           | Jie        | Buchanan  |
 | 1            | Kiran      | Coolidge  |
 +--------------+------------+-----------*/

다음 예제 역시 쿼리는 first_name과 last_name 기준으로 그룹화된다. total_points는 윈도우 함수 값이므로 제외됐다.

WITH PlayerStats AS (
  SELECT 'Adams' as LastName, 'Noam' as FirstName, 3 as PointsScored UNION ALL
  SELECT 'Buchanan', 'Jie', 0 UNION ALL
  SELECT 'Coolidge', 'Kiran', 1 UNION ALL
  SELECT 'Adams', 'Noam', 4 UNION ALL
  SELECT 'Buchanan', 'Jie', 13)
  
SELECT COUNT(*) OVER () AS total_people
  		, FirstName AS first_name
  		, LastName AS last_name
FROM PlayerStats
GROUP BY ALL;

/*--------------+------------+-----------+
 | total_people | first_name | last_name |
 +--------------+------------+-----------+
 | 3            | Noam       | Adams     |
 | 3            | Jie        | Buchanan  |
 | 3            | Kiran      | Coolidge  |
 +--------------+------------+-----------*/

여러 SELECT 항목이 FROM 절의 동일한 부분을 참고한다면 경로를 가장 직접적으로 지정한 하나만 GROUP BY의 대상이 된다. 아래 예제에서 coordinates의 두 구성 요소인 Values.x와 Values.y가 이미 직접 경로로 지정돼 있는 상태이므로 coordinates 컬럼은 GROUP BY에서 제외됐다.

WITH Values AS (
  SELECT 1 AS x, 2 AS y
  UNION ALL SELECT 1 AS x, 4 AS y
  UNION ALL SELECT 2 AS x, 5 AS y
)

SELECT Values.x AS x_coordinate
  	, Values.y AS y_coordinate
  	, [Values.x, Values.y] AS coordinates
FROM Values
GROUP BY ALL

/*--------------+--------------+-------------+
 | x_coordinate | y_coordinate | coordinates |
 +--------------+--------------+-------------+
 | 1            | 4            | [1, 4]      |
 | 1            | 2            | [1, 2]      |
 | 2            | 5            | [2, 5]      |
 +--------------+--------------+-------------*/

서브 쿼리Subquery란 메인 쿼리Main query를 실행하는 데 필요한 데이터를 추가로 조회하기 위해 사용되는 부가적인 SELECT문을 말한다. 어떤 메인 쿼리에 포함되어 있다는 의미에서 내부 쿼리Inner query라고 부르기도 한다. 이때, 메인 쿼리는 외부 쿼리Outer query로 지칭될 수 있다. 

서브 쿼리의 형태 / 실행 조건

SELECT 열
FROM 테이블
WHERE 조건식 ( SELECT 열
                             FROM 테이블
                             WHERE 조건식 )

(1) 반드시 괄호에 감싸진 형태로 쓰인다.

(2) SELECT문의 형태로만 작성이 가능하다.

(3) 쿼리의 끝에서 ;세미 콜론을 사용할 수 없다.

(4) ORDER BY절을 삽입할 수 없다.

서브 쿼리의 특징

(1) 비교 혹은 조회의 대상이 될 때 조회 대상의 오른쪽에 놓인다.

(2) 메인 쿼리와의 비교를 위해 존재하는 쿼리이기 때문에 서브 쿼리의 SELECT 절은 메인 쿼리의 비교 대상과 같은 자료형과 같은 개수로 지정돼야 한다.

(3) 결과값 역시 메인 쿼리의 연산자 종류와 동일해야 한다.

(4) 메인 쿼리와의 관계는 단방향이다. 이는 Java 객체지향의 상속과도 유사한 형태인데, 상속당한 자식 객체는 부모 객체의 인스턴스를 사용할 수 있지만 부모는 자식 객체의 인스턴스를 사용할 수 없는 특징이 있다.

(5) 구조화를 통해 쿼리의 각 부분을 가독성 있고 명확하게 볼 수 있게 해 준다.

(6) 위의 특징 때문에, 복잡한 JOIN과 UNION을 명료하게 정리할 수 있는 대체재로 기능할 수 있다. 

서브 쿼리의 사용처

(1) SELECT 절에서 사용 / 스칼라 서브 쿼리Scalar Subquery

(2) FROM 절에서 사용 / 인라인 뷰Inline View

(3) WHERE 절에서 사용 / 중첩 서브 쿼리Nested Subquery

(4) HAVING 절에서 사용

(5) ORDER BY 절에서 사용

(6) INSERT문의 VALUES 값 대체재로써 사용

(7) UPDATE문의 SET 값 대체재로써 사용

서브쿼리의 사용

이번 포스트에서는 서브 쿼리의 사용처 중 SELECT, FROM, WHERE절에서 쓰이는 경우, 즉 스칼라 서브 쿼리, 인라인 뷰, 중첩 서브 쿼리에 대해 알아본다.

SELECT절, 스칼라 서브 쿼리Scalar Subquery

ㅡ스칼라 서브쿼리(Scalar Subquery)
  정대리 급여와 테이블 전체 평균 급여를 구하시오.

SELECT name
	, salary
   	, (SELECT ROUND(AVG(salary), -1) FROM employee) AS 평균급여
FROM employee
WHERE name = '정대리';

스칼라 서브 쿼리는 SELECT절에서 나타나는 서브 쿼리다. 다른 테이블에서 어떠한 값을 불러올 때 주로 쓰이며, '스칼라'라는 이름에서 보여지듯 단일 값만을 가져올 수 있다. 해당 서브 쿼리는 일치하는 값이 없다면 NULL을 리턴한다(해당 부분은 그룹 함수의 특징이기도 하다.).

FROM절, 인라인 뷰Inline View

ㅡ인라인 뷰(Inline View)
  직급이 사원인 사람들의 이름과 급여를 구하시오.

SELECT ex1.name
	, ex1.salary
FROM (SELECT * FROM employee li
WHERE li.office_worker= '사원') ex1;

인라인 뷰는 FROM 절에서 나타나는 서브 쿼리다. 특정 테이블에서 전체 데이터가 아니라 일부 데이터만 추출해 연결하고자 할 때 쓴다. 타 서브 쿼리와 달리 꼭 별칭alias을 지정해 줘야지만 사용이 가능하다. 참고로, WITH 문을 사용해도 결과물은 동일하기 때문에 손에 맞는 것을 취사선택해 쓰면 된다.

WITH
[별칭1] AS (SELECT문 1),
[별칭2] AS (SELECT문 2),
...,
[별칭N] AS (SELECT문 N)
SELECT 
FROM 별칭1, 별칭2, ..., 별칭N

WHERE절, 중첩 서브 쿼리Nested Subquery

ㅡNested Subquery - 단일 행 
  정대리라는 사람의 직급을 구하시오.

SELECT office_worker
FROM employee
WHERE office_worker = (SELECT office_worker FROM employee WHERE name = '정대리')

ㅡNested Subquery - 복수(다중) 행 
  정대리보다 급여가 높은 사람들을 구하시오.

SELECT *
FROM employee
WHERE salary > (SELECT salary FROM employee WHERE name = '정대리')

  직급이 사원인 사람들을 구하시오.

SELECT *
FROM employee
WHERE office_worker IN (SELECT office_worker FROM employee WHERE office_worker = '사원')

WHERE절에서 나타나는 서브 쿼리는 중첩 서브 쿼리라 부른다. 실행 결과의 행 수, 열 수에 따라 단일 행 서브 쿼리, 다중 행 서브 쿼리, 다중 열 서브 쿼리로 나누며 이번 포스트에서는 실무에서 주로 사용되는 단일 행/ 다중 행 서브 쿼리만 다룬다. 

단일 행 서브 쿼리는 >, >=, =, <=, <, <>, ^=, != 등의 연산자와 함께 쓰이며, 다중 행 서브 쿼리는 IN, ANY, SOME, ALL, EXISTS 등의 연산자와 함께 쓰인다. 출력하는 행 수와 연결지어서, 전자를 단일 행 연산자, 후자를 다중 행 연산자라 부르기도 한다. 

IN : 하나라도 일치한 데이터가 있다면 TRUE
ANY, SOME : 만족하는 결과가 하나 이상이면 TRUE
ALL : 결과가 모두 만족하면 TRUE
EXISTS : 결과가 존재하면 TRUE (행이 1개 이상이면 TRUE)

 <IN> 부서별 최고 급여와 동일한 급여를 받는 사원 정보

SELECT *
FROM emp
WHERE sal IN (SELECT MAX(sal) FROM emp GROUP BY deptno);

 <SOME> 등가 비교 연산자(=)와 ANY, SOME을 함께 사용하면 IN 연산자와 같은 기능 수행

SELECT *
FROM emp
WHERE sal = SOME (SELECT MAX(sal) FROM emp GROUP BY deptno);

 <ANY> 등가 비교 연산자가 아닌 대소 비교 연산자와 ANY를 함께 사용하면?
 < ANY : 부서 30 중 최대값보다 적은 급여를 가진 사원을 찾게 됨
 > ANY : 부서 30 중 최소값보다 높은 급여를 가진 사원을 찾게 됨

SELECT *
FROM emp
WHERE sal < ANY (SELECT sal FROM emp WHERE deptno = 30);

 <ALL> 부서 30 중 최대 급여보다 더 많은 급여를 받는 사원 출력

SELECT *
FROM emp
WHERE sal > ALL (SELECT sal FROM emp WHERE deptno = 30);

 <EXISTS> 부서50이 있으면 EMP 전체 출력

SELECT *
FROM emp
WHERE EXISTS (SELECT dname FROM dept WHERE deptno = 50);

출처

양디로그 블로그

Inpa Dev 블로그

java의 개발일기 블로그

<데이터 체크>

<

문제 출처: 프로그래머스, 이름에 el이 들어가는 동물 찾기

테이블명: animal_ins동물 보호소에 들어온 동물의 정보를 담은 테이블

컬럼명: animal_id동물 아이디, animal_type동물 종, datetime보호시작일, intake_condition보호 시작 시 상태, name이름, sex_upon_intake성별 및 중성화 여부

데이터베이스 구성: 1개 테이블, 6개 컬럼, 100개 로우

>

<시나리오>

보호소에 돌아가신 할머니가 기르던 개를 찾는 사람이 찾아왔다. 이 사람이 말하길 할머니가 기르던 개는 이름에 'el'이 들어간다고. 동물 보호소에 들어온 동물 중 이름이 'el'이 들어가는 개의 리스트를 뽑으려면 어떻게 쿼리를 작성해야 할까.

<풀이> 

문제는, 개의 이름을 특정할 수 없으니 대소문자 역시 확답할 수 없다는 거다. 모든 경우의 수를 WHERE절에 넣어 주는 방향도 있겠지만, 문자열을 전부 대문자나 소문자로 바꿔 버리는 UPPER나 LOWER를 사용해도 동일한 결과물을 구현할 수 있다.

WHERE name LIKE LOWER('%EL%')

나머지는 쉽다. 조건을 채워서 쿼리를 마저 짜면 아래와 같을 것이다.

SELECT animal_id
        , name
FROM animal_ins
WHERE name LIKE LOWER('%EL%')
    AND animal_type = 'Dog'
ORDER BY name

<데이터 체크>

<

문제 출처: 프로그래머스, 자동차 평균 대여 기간 구하기

테이블명: car_rental_company_rental_history어느 자동차 대여점의 대여 기록 테이블 견본 

컬럼명: history_id대여 기록 아이디, car_id자동차 아이디, start_date대여시작일, end_date대여종료일

데이터베이스 구성: 1개 테이블, 4개 컬럼, 160개 로우

>

>

<시나리오>

여기 어떤 자동차 대여점이 있다. 이 자동차 대여점에서는 기존 고객들을 확실히 잡아두기 위해 주 고객층에 최대한의 가격 메리트를 부여하는 방향으로 가격 정책을 개편하려고 한다. 이번 EDA탐색적 데이터 분석는 이를 위한 고객 세분화 과정이다. 평균 대여 기간이 7일 이상인 자동차들의 평균 대여 기간(컬럼명: average_duration) 리스트를 출력하는 SQL문을 작성하려면 어떻게 해야 할까?

<풀이>

먼저 문제를 해소하기 위해서는 전체 리스트의 평균 대여 기간을 리스트화해야 한다. 파편화되어 있는 데이터를 그룹으로 묶어 주고,

GROUP BY car_id

이 데이터의 기준으로 평균 대여 기간을 뽑는다. 대여 기간은 대여종료일과 대여시작일의 차로 계산될 수 있는데, 이 때 대여시작일 역시 하루로 계산되기 때문에 꼭 1을 더해 줘야 한다. 이 값에 평균을 적용해 주고 가독성을 위해 소수점 첫째 자리까지 반올림하는 쿼리를 다음과 같이 짤 수 있다.

SELECT car_id
	, ROUND(AVG(DATEDIFF(end_date, start_date) + 1), 1) average_duration

이 중에서 평균 대여 기간이 7일 이상인 값을 뽑으려면 HAVING에 조건을 추가해주면 된다. WHERE가 아닌 HAVING에 넣는 이유는 그룹의 집계값(AVG) 기준으로 연산해야 하기 때문이다.

HAVING average_duration >= 7

마무리하면, 완성된 식은 아래와 같을 것이다.

SELECT car_id
        , ROUND(AVG(DATEDIFF(end_date, start_date) + 1), 1) average_duration
FROM car_rental_company_rental_history
GROUP BY car_id
HAVING average_duration >= 7
ORDER BY average_duration DESC, car_id DESC

<서론>

실무에서는 종종 두 개 이상의 테이블의 모든 데이터ㅡ기준키가 공백인 데이터를 포함한, 다시 말해 합집합ㅡ를 불러와야 할 경우가 생긴다. 타 데이터베이스에서는 이를 FULL OUTER JOIN이라는 이름으로 지원하지만, mysql에서는 아쉽게도 이를 공식적으로 지원하고 있지 않다. 그러면 mysql에서는 합집합을 구현할 수 없냐고? 그건 아니다. LEFT JOIN과 RIGHT JOIN을 결합하는 것으로 mysql에서도 이를 간접적으로 구현할 수 있다. 외국 블로그에 해당 내용에 대해 예제와 함께 표시한 포스트가 있어 번역해 가져와 본다.

<본문>

sales와 orders라는 두 테이블이 있다고 가정해 보자. sales와 orders에는 동일하게 id주문 아이디와 order_date(형식이 살짝 다른)주문 일자, amount주문 금액 데이터가 들어 있다.

SELECT *
FROM sales;

 +------+---------------------+--------+
 | id   | order_date          | amount |
 +------+---------------------+--------+
 |    1 | 2021-02-02 08:15:00 |    250 |
 |    2 | 2021-02-02 08:30:00 |    200 |
 |    3 | 2021-02-02 08:55:00 |    150 |
 |    4 | 2021-02-02 09:15:00 |    125 |
 |    5 | 2021-02-02 09:30:00 |    250 |
 |    6 | 2021-02-02 09:45:00 |    200 |
 |    7 | 2021-02-02 10:15:00 |    180 |
 |    8 | 2021-02-02 10:30:00 |    125 |
 |    9 | 2021-02-02 10:45:00 |    200 |
 |   10 | 2021-02-02 11:15:00 |    250 |
 |   11 | 2021-02-02 11:30:00 |    150 |
 |   12 | 2021-02-02 11:45:00 |    200 |
 +------+---------------------+--------+


SELECT *
FROM orders;

 +------+------------+--------+
 | id   | order_date | amount |
 +------+------------+--------+
 |    5 | 2021-01-28 |    250 |
 |    6 | 2021-01-29 |    250 |
 |    7 | 2021-01-30 |    250 |
 |    8 | 2021-01-31 |    250 |
 |    9 | 2021-02-01 |    250 |
 +------+------------+--------+

만약 당신이 전체 기간 동안의 매출 합계를 계산한다거나 하는 이유로 두 테이블을 합쳐야 할 필요성이 있다면 아래와 같이 LEFT JOIN과 RIGHT JOIN을 UNION ALL로 결합해 사용할 수 있다. 아래와 같은 식으로.

mysql> SELECT * FROM sales
       LEFT JOIN orders ON sales.id = orders.id
       UNION ALL
       SELECT * FROM sales
       RIGHT JOIN orders ON sales.id = orders.id
       WHERE sales.id IS NULL ;
       
 +------+---------------------+--------+------+------------+--------+
 | id   | order_date          | amount | id   | order_date | amount |
 +------+---------------------+--------+------+------------+--------+
 |    5 | 2021-02-02 09:30:00 |    250 |    5 | 2021-01-28 |    250 |
 |    6 | 2021-02-02 09:45:00 |    200 |    6 | 2021-01-29 |    250 |
 |    7 | 2021-02-02 10:15:00 |    180 |    7 | 2021-01-30 |    250 |
 |    8 | 2021-02-02 10:30:00 |    125 |    8 | 2021-01-31 |    250 |
 |    9 | 2021-02-02 10:45:00 |    200 |    9 | 2021-02-01 |    250 |
 |    1 | 2021-02-02 08:15:00 |    250 | NULL | NULL       |   NULL |
 |    2 | 2021-02-02 08:30:00 |    200 | NULL | NULL       |   NULL |
 |    3 | 2021-02-02 08:55:00 |    150 | NULL | NULL       |   NULL |
 |    4 | 2021-02-02 09:15:00 |    125 | NULL | NULL       |   NULL |
 |   10 | 2021-02-02 11:15:00 |    250 | NULL | NULL       |   NULL |
 |   11 | 2021-02-02 11:30:00 |    150 | NULL | NULL       |   NULL |
 |   12 | 2021-02-02 11:45:00 |    200 | NULL | NULL       |   NULL |
 +------+---------------------+--------+------+------------+--------+

다만 UNION ALL의 경우 합집합이기 때문에 중복 행이 섞여 나올 수 있다. 이럴 경우에는 UNION을 사용해 주면 되는데, UNION의 경우에는 t1과 t2 사이의 중복 값을 걸러서 출력하는 것이어서 유니크 값을 거르는 인덱스가 하나 더 추가된다고 한다. 그래서 ㅡ중복을 거르지 않는 UNION ALL과 대비해서ㅡ 데이터의 크기에 따라 1.5배에서 4배까지 성능 차이가 날 수도 있다고.

그러니까, 웬만하면 FULL OUTER JOIN을 사용할 때는 UNION ALL을 쓰는 게 효율적이겠다. (+ 최소한으로 SELECT해서.)물론 애초에 모델링 차원에서 결합할 일을 배제하도록 설계하는 게 가장 좋겠지만.

<정리>

마지막으로 문법을 정리해 두고 글을 마친다. 순서대로 UNION ALL중복 미제거, UNION중복 제거으로 FULL OUTER JOIN을 적용하는 쿼리다.

SELECT * FROM t1 
LEFT JOIN t2 ON t1.id = t2.id 
UNION ALL 
SELECT * FROM t1 
RIGHT JOIN t2 ON t1.id = t2.id 
WHERE t1.id IS NULL

SELECT * FROM t1 
LEFT JOIN t2 ON t1.id = t2.id 
UNION 
SELECT * FROM t1 
RIGHT JOIN t2 ON t1.id = t2.id

<참고>

ubiq 블로그

sewonzzang님 블로그

<데이터 체크>

<

문제 출처: 프로그래머스, 식품분류별 가장 비싼 식품의 정보 조회하기

테이블명: food_product어느 대형마트의 식품 정보 테이블 견본 

컬럼명: product_id제품식별코드, product_name제품명, product_cd식품코드, category카테고리명, price가격

데이터베이스 구성: 1개 테이블, 5개 컬럼, 40개 로우

>

<시나리오>

당신은 A식품 영업팀 담당자다. 데이터를 통해 정량적으로 제품별 판매 성과를 확인하고자 마트 전산 기재된 자사 상품 기반으로 EDA탐색적 데이터 분석를 진행해보려고 한다. food_product 테이블에서 식품분류별로 가격이 가장 비싸거나 싼 '과자', '국', '김치', '식용유'의 category, price, product_name을 조회하고 싶다면 어떻게 쿼리를 짜야 할까?

<풀이>

'식품분류별' 이라 했으니 상품을 그룹으로 묶어야 한다. 또, GROUP BY와 윈도우 함수 중에는 윈도우 함수를 사용해야 한다. 왜냐면 연산된 결과값이 아니라 연산에 맞는 값을 가진 로우의 리스트를 출력해야 하니까. 이 부분에 대해 좀 더 깊이 알고 싶다면 윈도우 함수Window Function VS GROUP BY 포스트를 읽으면 된다.

WHERE절이 길어지겠다. 1) '과자', '국', '김치', '식용유' category의 상품 중에 2) 식품분류별로 가격이 가장 비싸거나/ 싼 상품만 골라 출력해야 하니까. 이를 반영해 WHERE절을 쓰면 아래와 같다. 이를 보면 서브쿼리를 IN 뒤에 조건절로 넣어 줬는데, 이에 대해 궁금하다면 다중행 서브쿼리 관련해 찾아보면 된다.

WHERE category IN('과자', '국', '김치', '식용유')
        AND price IN (SELECT MAX(price) OVER (PARTITION BY category) FROM food_product)
        -- 가장 비싼 상품의 리스트를 출력하거나

WHERE category IN('과자', '국', '김치', '식용유')
        AND price IN (SELECT MIN(price) OVER (PARTITION BY category) FROM food_product)
        -- 가장 싼 상품의 리스트를 출력하거나

또한 전문은 아래와 같이 쓸 수 있을 것이다. 

SELECT category
        , price
        , product_name
FROM food_product
WHERE category IN('과자', '국', '김치', '식용유')
        AND price IN (SELECT MAX(price) OVER (PARTITION BY category) FROM food_product)
        -- 가장 비싼 상품들만 출력
ORDER BY price DESC

SELECT category
        , price
        , product_name
FROM food_product
WHERE category IN('과자', '국', '김치', '식용유')
        AND price IN (SELECT MIN(price) OVER (PARTITION BY category) FROM food_product)
        -- 가장 싼 상품들만 출력
ORDER BY price DESC

<GROUP BY와 윈도우 함수Window Function는 어떻게 다른가>

윈도우 함수Window Function는 '행을 조건에 맞게 구분해 주는' 함수다. 이쯤 말하면 당신 머릿속에 떠오른 문법이 하나 있을 것이다. 맞다. GROUP BY. 이것 역시 행을 조건에 맞게 구분해 준다. 그러면 의문이 든다. GROUP BY 절과 대비해 윈도우 함수는 어떤 차이점이 있고 그래서 결국 어떤 상황에 사용되는 걸까. 이번 포스트는 이처럼 유사한 문맥에서 사용되는 두 문법, GROUP BY 절과 윈도우 함수의 차이에 대해 탐구해볼 것이다.

<'행을 묶는다' 는 행동에 대한 이해>

문법에 대해 다루기 앞서서 즉 '행을 묶는다'는 행동에 대해 먼저 이해할 필요가 있다. 행을 묶는다는 것은 일차적으로 행 사이의 공통점을 찾는다는 뜻이다. 아래와 같은 엑셀 파일이 있다고 가정해 보자. 

이 엑셀 파일에 '행을 묶으면' 어디에 포커스를 두느냐에 따라 아래와 같이 두 가지 결과물이 나올 수 있다.

1) 행에 포커스를 두는 경우. 아래는 성별 기준으로 행을 묶어서 성별 별 최연장자를 각각 출력한 경우다.

2) 연산한 값에 포커스를 두는 경우. 아래는 이름의 첫 글자, 성 기준으로 행을 묶어서 성 별 나이 최대값을 각각 출력한 경우다.

둘 모두 포커스만 다르지 '행을 묶었다'고 부를 만하다. 이때 후자는 GROUP BY로 구현할 수 있지만, 전자는 어렵다. GROUP BY는 특성상 동일한 기준을 가진 로우들을 하나로 '합치고' 들어가기 때문이다. 그래서 GROUP BY를 가진 쿼리의 SELECT 절에는 GROUP BY된 컬럼과 합쳐진 값들을 연산하는 집계함수밖에 올 수 없는 것이다. 이때 전자는 윈도우 함수로 구현될 수 있다.

<윈도우 함수Window Fuction>

'행과 행 간의 관계를 정의하거나 비교, 연산을 수행할 수 있는 함수'가 윈도우 함수에 대한 정의다. 위에서 알아봤듯이 GROUP BY는 동일한 기준을 가지는 로우들을 다 합쳐 버리지만, 윈도우 함수는 보존해 준다. 이 때문에 GROUP BY로 하지 못 하는 결과를 출력 가능하다. 그룹 내에서 순위/ 비율 뽑기, 연산에 맞는 결과 로우 출력하기(최대값을 가진 사람의 이름을 불러온다거나) 등.

윈도우 함수는 아래와 같은 형식으로 쓰인다.

SELECT WINDOW_FUNCTION (ARGUMENTS) OVER 
( [PARTITION BY 컬럼] [ORDER BY 컬럼] [WINDOWING 절] )
FROM 테이블명 ; 

   1) WINDOW_FUNCTION : 윈도우 함수 

   2) ARGUMENTS(인수) : 함수에 따라 0 ~ N개 인수가 지정될 수 있다. 

   3) PARTITION BY 절 : 전체 집합을 기준에 의해 소그룹으로 나눌 수 있다.   

   4) ORDER BY 절 : 어떤 항목에 대해 순위를 지정할 지 order by 절을 기술한다.

   5) WINDOWING 절 : WINDOWING 절은 함수의 대상이 되는 행 기준의 범위를 강력하게 지정할 수 있다. 

이때의 WINDOW_FUNCTION에는 전용 윈도우 함수 외에도 다양한 기존 함수를 가져다 쓸 수 있는데, 이 부분을 이 포스트에서 정리하지는 않고 참고 포스트 중 해당 내용에 대해 잘 정리한 포스트가 있어 재인용한다*링크는 SQL 전문가 가이드 2013 Edition를 요약했다고 한다. 해당 포스트를 참조해 쓰면, WINDOW_FUNCTION에는 다음과 같은 함수들이 올 수 있다.

   1) 순위 함수: RANK, DENSE_RANK, ROW_NUMBER

   2) 집계 함수: SUM, MAX, MIN, AVG, COUNT

   3) 비율 함수: CUME_DIST, PERCENT_RANK, NTILE, RATIO_TO_REPORT

윈도우 함수는 SQL의 다른 문법들보단 꽤 난이도가 있어 진입장벽이 높지만, 일단 익혀두고 나면 쿼리 다이어트에 도움을 주는 효자 함수다. 시간 내서 익숙해져 보자.

<문제>

<원본 문제: HackerRank The Report>

시험이 끝났다. 하지만 불행히도 당신은 학교 선생님이다. 아이들이 가벼운 마음으로 하교하는 것과 별개로 당신은 채점된 점수 기준으로 아이들의 등급을 매겨야 할 중요한 책무를 수행해야 한다. 당신 앞에는 Students 테이블과 Grades 테이블이 놓여 있다. 하나는 학생의 이름과 점수가 들어 있는 테이블이고 나머지 하나는 점수를 기준으로 학생을 그룹 나누는 등급 테이블이다. 두 테이블은 다음과 같은 값을 가진다. 비교적 덜 삽질하고 아이들의 등급을 매길 쿼리를 짤 방법은 없을까.

<풀이>

물론 저번과 마찬가지로 CASE WHEN으로 일일이 지정해주는 방법도 있겠지만, MIN 값과 MAX 값이 있는 테이블이 이렇게 예쁘게 있다면 LEFT JOIN으로 묶고 BETWEEN만 걸어 줘도 전체 등급을 뽑을 수 있다. LEFT JOIN은 INNER JOIN과 다르게 두 테이블에 동일한 값이 없어도 사용 가능하므로, 일단 옆에 붙여 놓고 같은 테이블에 있는 것처럼 연산에만 뽑아 쓰는 것이다.

SELECT IF(Grade < 8, NULL, Name), g.Grade, s.Marks
FROM Students s
	LEFT JOIN Grades g ON s.Marks BETWEEN g.Min_Mark AND g.Max_Mark
ORDER BY Grade DESC, Name, Marks

<문제>

<원본 문제: 프로그래머스 가격대별 상품 개수 구하기>

어떤 온라인 쇼핑몰이 있다고 하자. 이 쇼핑몰은 만 원 대부터 팔만 원 대까지 다양한 가격대의 상품을 취급하고 있다. 어느 날 프로덕트 팀에서 데이터 추출 요청이 들어왔다. 제품을 가격대별로 프로모션 진행하려 하니 만 원 단위로 그룹을 나눠 달라고. 이런 상황에서는 쿼리를 어떻게 짜야 할까? 제품 정보가 들어 있는 product 테이블은 다음과 같다.

<풀이>

CASE WHEN으로 일일이 지정해줘도 되지만, 가격이 들어간 컬럼이 있는 상황이므로 조건에 부합되는 대로 계산해서 답을 뽑아도 된다. FLOOR와 TRUNCATE로 각각 아래와 같이 풀 수 있다.

(1) FLOOR

아래와 같이 가격을 10000으로 나눈 뒤 FLOOR를 적용해 주면 각 가격대별로 유니크한 그룹으로 묶인다.   

SELECT FLOOR(price / 10000)*10000 AS price_group
             , COUNT(product_id) AS products
FROM product
GROUP BY price_group
ORDER BY price_group

(2)TRUNCATE

아래처럼 CASE WHEN으로 10,000원 미만 상품을 NULL 값으로 빼 버린 뒤 나머지를 TRUNCATE 해 줘도 동일한 방식으로 묶인다.

SELECT CASE
        WHEN price < 10000 THEN NULL
        ELSE TRUNCATE(price, -4) END AS price_group
        , COUNT(product_id) AS products
FROM product
GROUP BY price_group
ORDER BY price_group

결과값은 아래와 같이 나온다.

GROUP BY에 product_code를 넣어 주면 아래와 같이 그룹별 상품코드를 조회할 수 있겠다.

왜 NULL은 =이 아니라 is를 쓸까

SQL 문법을 처음 배울 때, 꼭 배우는 것이 있다. 'NULL을 찾을 때는 = NULL이 아니라 IS NULL을 사용해야 한다'. 의아하다. 대부분의 프로그래밍 언어에서는 (논리 연산에서) NULL을 0과 같이 취급하지 않는가. SQL에는 어떤 차이점이 있길래 이처럼 특별하게 NULL을 다룰까. 이번 포스트에는 SQL식 NULL의 정의에 대해 알아보면서 위 의문에 대해 파헤쳐 본다.

데이터가 '존재하지 않는 값' 그래서 '아직 모르는 값'

SQL에서의 NULL은 위키백과 기준으로 이렇게 정의된다. 'Null 또는 NULL은 구조적 질의언어(SQL)에서 데이터베이스 내의 값이 존재하지 않는다는 것을 지시하는 데 사용되는 특별한 표시어(Special marker)'. 

이처럼 NULL은 '존재하지 않는 값'이다. 0도 아니고 STRING도 아니고 다른 어느 타입도 아닌 그냥 알 수 없는 값. 데이터베이스에서 값이 존재하지 않는다는 사실을 따로 빼 둘 수 있다는 건 굉장히 중요한 의미를 가진다.

예를 들어, Primary Key를 설정한다고 하자. PK는 NOTNULL, NULL 값이어서는 안 된다. SQL에서는 PK에 NULL이 들어오면 오류를 출력한다. 이로써 의미 없는 로우를 사전에 걸러 낼 수 있다. 다른 컬럼의 경우에도 NULL의 활용이 가능하다. 'NULL'이라는 '존재하지 않는 값'이 이미 존재하니 '0'이나 '9999' 처럼 의미 없는 수로 존재하지 않는 값을 재정의할 필요가 없다. 이처럼 SQL은 NULL을 체크함으로써 SQL는 데이터베이스 자체의 정합성을 확고히 하고 있다.

NULL의 특성

위처럼 SQL의 NULL은 타 언어와 다른 형태로 정의되기 때문에 연산도 조금 다른 방식으로 이뤄진다. 아래에서 직접 예시와 함께 보면서 NULL의 특성을 알아보자.

1) 사칙연산

위와 같은 테이블이 있다고 하자. 첫 번째 로우는 NULL이고 두 번째 로우는 정수다. 이 테이블에 사칙연산을 적용하면: 

SELECT A + 5, A - 5, A * 5, A / 5 FROM nullcheck;

네 연산 모두 동일하게 NULL 값이 출력되는 걸 알 수 있다. 모르는 값에 숫자를 더하고 빼 봐야 여전히 알 수 없는 값인 것이다. 

2) 비교연산

이번에는 비교연산을 진행해 보자. 아래와 같은 테이블에 비교연산을 적용하면:

A = B, A > B, A < B를 각각 적용했을 때 A < B에서 둘 다 정수인 로우가 출력되는 것 외에 나오는 게 없다. 눈여겨볼 점은 1과 NULL뿐 아니라  NULL과 NULL끼리도 안 됐다는 점이다. SQL에서 NULL 값은 '알 수 없는 값' 이므로 알 수 없는 값 사이의 비교는 불가하다.

3) 집계함수

이번엔 집계함수다. 아래 테이블에 집계함수를 적용해 보면:

SELECT COUNT(*), COUNT(구매금액), SUM(구매금액), AVG(구매금액), MAX(구매금액), MIN(구매금액)
FROM zipge;

사칙연산에서처럼 출력이 아예 안 되는 게 아니라 NULL값을 자동으로 빼고 이외의 값을 연산해 준다. 다만, COUNT와 AVG는 주의할 필요가 있어 보인다. 상기 쿼리에서 COUNT(*)와 COUNT(구매금액)은 서로 다른 값을 리턴했다. 주문번호 10003은 주문금액이 NULL이지만 주문번호가 들어가 있으므로 COUNT(*)에서는 값으로 집계된 것이다. AVG의 경우에는 전체 구매액인 19000을 해당 컬럼에서 NULL이 아닌 로우인 3으로 나눈 값으로 출력됐다. 결과적으로 SUM(구매금액) / COUNT(*)와는 서로 다른 답을 출력하게 됐다.

NULL을 TRUE 아니면 FALSE로 설명할 수 있는 유일한 방법

이처럼 SQL은 NULL을 걸러내기 위해 기존 언어에서 사용되던 TRUE, FALSE로 이루어진 2값 논리에 NULL을 추가한 3가 논리(Three-valued logic)를 사용하고 있다.

이제 우리는 처음의 질문에 답할 수 있다. "왜 NULL은 =이 아니라 is를 써야 할까."

답변은 이쯤 되겠다. NULL은 TRUE나 FALSE로 설명될 수 없는 제 3의 값이다. 그래서 NULL은 비교연산될 수 없다. 말 그대로 모르는 값이기 때문이다. 그래서 SQL은 'NULL을 TRUE나 FALSE 두 가지로 비교연산할 수 있는' 문법을 만들었고 이게 IS NULL과 IS NOT NULL이었을 것이다.

참고

1) https://khdscor.tistory.com/53

2) https://yoongaemii.github.io/null_in_sql/

3) https://velog.io/@minnim1010/SQL-NULL-%EC%9D%B4-%EC%95%84%EB%8B%8C-IS-NULL%EC%9D%B8-%EC%9D%B4%EC%9C%A0-9irf8u7o

CASE WHEN(CASE 문이라고도 한다.)은 SQL의 조건문이다. 기준 컬럼 A가 B라는 조건을 만족하면 C라는 값을 출력하는 형태로 'CASE WHEN A = B THEN C'와 같이 표현된다. "조건에 맞는 답을 출력"하는 식이어서 주로 SELECT 절이나 집계함수에서 쓰인다. 이번 포스트에서는 샘플 데이터베이스 기반으로 아직 집계되지 않은 유의미한 지표를 찾아 반환해 보고 이를 통해 CASE WHEN의 SELECT절 용례를 살펴보려 한다.

사용 데이터베이스

아래로 한 데이터베이스가 있다. (mySQL에서 기본적으로 제공하는 샘플이다.) 우리는 이 데이터베이스의 테이블들을 살펴보고 CASE WHEN을 통해 회사 운영 전반에 유의미한 정보를 만들어 볼 것이다. 이 데이터베이스에는 여덟 개의 테이블이 있다. customers, employees, offices, orderdetails, orders, payments, productline, products...... 이 회사에서 무슨 일을 하는지는 아직 알 수 없지만 프로덕트 정보, 주문 정보를 가진 것으로 보아 어떤 프로덕트를 판매하는 커머스임을 우선 알 수 있다. 그게 유형의 제품이든, 무형의 제품이든간에. 우선 products를 한 번 볼까.

위 사진은 products의 데이터를 일부 출력한 것이다. 익숙한 자동차/ 오토바이 브랜드가 보이는데, 전반적으로 엄청 옛날 것이고(productName) 재고 수량도 너무 많다. 좀 더 살펴 보니 productScale이라는 컬럼이 있다. 1:10, 1:12...... 자동차 미니어처를 파는 회사임을 알 수 있다. 제조 벤더사(productVender)가 여럿인 것으로 봐선 제조사보다는 유통사에 가까운 회사겠다.

중요한 부분은 주로 뒤에 있다. 재고 수량(quantityInstock), 구매원가(buyPrice), 판매가(MSRP). 판매 데이터와 함께 보면 뜯어볼 부분이 많아 보인다. 하지만 이 회사 데이터베이스엔 판매 데이터가 없기 때문에 주문 데이터를 통해 추출해내야 할 것 같다.

다음으로 살펴 볼 테이블은 orderdetails 테이블이다. 제품의 개당 단가와 주문 수량이 있고 productCode로 products 테이블과 연결돼 있다. 주문 수량이 쭉 나열돼 있기 때문에 products와 orders를 함께 보면 제품의 평균 주문 수량이나 총 매출액, 잔여 재고수량, 안전 재고 등의 확인이 가능하겠다. 아쉬운 것은, 주문 일자가 없다. 기간별로 그룹해 볼 수 없으니 유의미한 정보를 만들어낼 수는 없다. 그러면 테이블 하나가 더 필요하겠다. 

바로 orders 테이블이다. 이 테이블에는 주문 일자(orderDate)와 주문한 사람의 고객 번호(customerNumber), 그리고 주문 번호가 적혀 있다. 테이블을 살펴 보니 2003년 01월부터 2005년 05월까지의 데이터가 저장돼 있다. 이걸로 필요한 데이터는 모두 모아졌다. 이제 데이터를 예쁘게 다듬어보자.

INNER JOIN: 여러 테이블 모아서 보기

CASE WHEN은 조건을 다는 데 수량 제한이 없다. 원하는 수량만큼 충분히 덧붙일 수 있단 소리다. SELECT 절에서 CASE WHEN을 사용하면 새로운 컬럼에서 구간에 맞춰 값을 다시 부여함으로써 로우들을 세분화할 수 있다. 하지만 한 테이블에서만 진행하기는 조금 어렵다. 각 정보값이 두 테이블에서 공유하는 값(기본키)을 기준으로 나눠져 있기 때문이다. 이를 테면, orderdetails에서는 제품의 값과 주문 수량이 있지만 주문 일자와 주문자명이 없다. 이 두 정보값은 orders 테이블에서 가져와야 한다.

우리는 이미 이전 포스트에서 JOIN에 관해 배웠다. INNER JOIN을 활용하면 각기 두 테이블에서 원하는 컬럼을 각각 가져와 재조립해 SELECT 할 수 있다. 아래와 같이 말이다.

SELECT ods.orderDate
, ods.customerNumber
, odd.orderNumber
, odd.productCode
        , odd.quantityOrdered
        , odd.priceEach
FROM orderdetails odd, orders ods
WHERE odd.orderNumber = ods.orderNumber

이렇게 INNER JOIN으로 정보를 각각 가져와 주면, 일자별로 어떤 상품이 누구에게 얼마나 팔렸는지 알 수 있다. 이 테이블을 기준으로 2003년 기준으로 제품별 매출 순위를 뽑아 볼 수 있을 것이다.

WHERE, GROUP BY: 1년치 제품별 매출 순위 뽑기

SELECT ods.orderDate
, ods.customerNumber
, odd.orderNumber
, odd.productCode
        , odd.quantityOrdered
        , odd.priceEach
FROM orderdetails odd, orders ods
WHERE odd.orderNumber = ods.orderNumber
AND orderDate LIKE '2003%'
ORDER BY productCode;

WHERE 절에 조건을 하나 더 추가해 줬다. 2003년으로 시작하는 문자열 전체를 반환하는 조건이다. ORDER BY는 productCode로 줬다. 제품 코드 별로 데이터가 정렬된 게 보인다. (시기나 고객 집단의 차이에 따라 최종 판매가는 오르내리는 게 보인다.) 여기다 상품별 연매출액을 뽑고 정렬해 주면 예쁘게 볼 수 있겠다.

SELECT productCode
, ROUND(AVG(priceEach), 2) AS avg_priceEach
    , SUM(quantityOrdered) AS sum_quantity
    , (ROUND(AVG(priceEach), 2) * SUM(quantityOrdered)) AS year_sales
FROM orderdetails odd, orders ods
WHERE odd.orderNumber = ods.orderNumber
AND orderDate LIKE '2003%'
GROUP BY productCode
ORDER BY year_sales DESC;

훨씬 보기 편해졌다. 여기서 들 수 있는 의문을 해소하고 갈까. 왜 priceEach는 평균을 구하고 quantity는 합계 값을 구하는가가 궁금할 수 있다. 그건 priceEach가 구매액(개당 단가*수량)이 아니라 개당 단가여서 그렇다. 해당 회사의 경우 도매로만 거래하기 때문에 제품 가격이 고정되어 있지 않고 협의 여부와 상황에 따라 유동적으로 단가가 조정된다. 그래서 연매출, year_sales를 뽑기 위해서는 이 개당 실판매가의 평균과 판매 개수를 곱해야만 했다.

CASE WHEN: 상품 세분화해서 각기 다른 프로모션 전략 짜기

보면 알겠지만, 매출 1위 상품과 2위 상품의 편차가 크다. 쭉 내려보면 막순위 상품은 1만 달러 정도로 1위와 거의 10배 가량 매출 차이가 나는데 상위권 상품 대비해서 제품 단가도 낮고 판매 수량 좀 부진하다. 전반적으로 보면 그룹별로 나눠서 관리해줘야 할 필요가 있다. 

SELECT productCode
, ROUND(AVG(priceEach), 2) AS avg_priceEach
    , SUM(quantityOrdered) AS sum_quantity
    , (ROUND(AVG(priceEach), 2) * SUM(quantityOrdered)) AS year_sales
    , ROW_NUMBER () 
OVER (
ORDER BY (ROUND(AVG(priceEach), 2) * SUM(quantityOrdered)) DESC
            ) AS sales_rank
FROM orderdetails odd, orders ods
WHERE odd.orderNumber = ods.orderNumber
AND orderDate LIKE '2003%'
GROUP BY productCode
ORDER BY year_sales DESC;

year_sales를 조금 더 직관적으로 보고, 차후에 다른 년도별 세분화 진행 시에도 사용 가능하도록 순위를 먼저 뽑았다. 이 데이터를 기반으로 상품을 'high', 'medium', 'low' 세 가지 집단으로 나눠볼 것이다. 'high'는 매출 상위권으로 재고를 지속 관리해줘야 하며 판매 동향을 지속적으로 체크해야 할 상위 십 퍼센트, 반대로 'low'는 재고가 과다하다면 최우선으로 소진하고 재고를 감축 운영해야 할 하위 십 퍼센트다.

퍼센트를 직접 집계하는 쿼리를 짜고 싶었는데 서칭 실력이 부족했던 건지 결국 못 찾아서, 전체 리스트를 10으로 나눠서 위 아래로 11위씩 빼 줬다(...)

SELECT productCode
, ROUND(AVG(priceEach), 2) AS avg_priceEach
    , SUM(quantityOrdered) AS sum_quantity
    , (ROUND(AVG(priceEach), 2) * SUM(quantityOrdered)) AS year_sales
    , ROW_NUMBER () 
OVER (
ORDER BY (ROUND(AVG(priceEach), 2) * SUM(quantityOrdered)) DESC
            ) AS sales_rank
, CASE 
WHEN ROW_NUMBER () 
OVER (
ORDER BY (ROUND(AVG(priceEach), 2) * SUM(quantityOrdered)) DESC
            ) BETWEEN 1 AND 11 THEN 'high'
WHEN ROW_NUMBER () 
OVER (
ORDER BY (ROUND(AVG(priceEach), 2) * SUM(quantityOrdered)) DESC
            ) BETWEEN 98 AND 109 THEN 'low'
ELSE 'medium'
END AS sales_seg
FROM orderdetails odd, orders ods
WHERE odd.orderNumber = ods.orderNumber
AND orderDate LIKE '2003%'
GROUP BY productCode;

결과적으론 잘 나왔다! 가독성 위해 BETWEEN으로 값을 지정해 줬는데 연산부호로 잡아 줘도 무방하겠다. 굳이 순위를 집계한 까닭은 이후에 일일이 범위를 지정할 필요가 없어서다. year_sales를 조건으로 잡다 보니 많이 길어졌는데, 더 효율 좋게 짤 수 있는 방법이 분명 있지 않나 싶다. 차후 알게 되면 와서 덧붙여 보겠다.

CASE WHEN을 사용할 때 주의할 점이 몇 가지 있다. 1) 상위 조건이 우선순위로 잡혀 있어서 우선순위 설정 시 겹치지 않게 넣어 줘야 한다는 거. 만약에 위 쿼리를 연산기호로 조건을 겹칠 수 있게 잡아 뒀다면 먼저 선언된 한 가지 집단에 값들이 다 몰려 버리는 결과가 나올 수 있다. 해당 문법은 한 번 포함된 이후의 만족 조건을 무시하기 때문이다. 2) ELSE를 넣지 않아도 동작하지만 지정해주지 않으면 세분화되지 않는 로우는 전부 다 NULL 값이 들어간다는 거다. 해당 두 가지를 주의해서 짜 주자.

참고

suy379님 티스토리

mySQL 샘플 데이터베이스

분석 툴을 사용해 데이터를 뽑다 보면 가끔 당황스러울 때가 있다. 고유 번호까지 동일한 데이터가 여러 개 나오는 거다. 이유가 어떻든(우리가 변별력 없는 조건을 설정했든, 말 그대로 컴퓨터가 실수를 했든) 간에 이 값들은 걸러져야 하고 반대로 수집 프로세스 자체의 보수를 위해 집계되기도 해야 한다.

아래 order_list는 가상의 브랜드의 주문 정보 수집 내역이다. 이 중 주문번호 10251은 두 번 나오는데 보다시피 고객ID를 포함한 모든 정보값이 동일하다. 기재하진 않았지만 수집된 시간까지. 오늘은 이 데이터를 기준으로 중복 값 제거/ 집계 관련한 쿼리 작업을 진행해보겠다.

order_list

* learnsql 포스트를 번역해 공유한 것.

문제를 풀기 위해서, 우선 '중복'의 조건을 정의할 필요가 있다. 중복이 발생하려면 완전히 동일한 데이터가 2개 이상 존재해야 한다. '완전 동일' 을 판단하는 기준이 돼 줄 컬럼은 명확하다. 중복될 수 없는 고유한 값, 기본 키인 '주문번호'다. 그렇다면 주문번호끼리 그룹을 묶어 정렬하고 그룹별 수량을 센다면 중복이 조금 더 명확히 보이지 않을까.

SELECT 주문번호

               , COUNT(주문번호) AS 중복체크 FROM order_list
GROUP BY 주문번호
HAVING COUNT(주문번호);

order_list

주문번호의 중복이 잡힌 10251 말고는 전체가 1로 체크되는 걸 알 수 있다. 그렇다면, 여기서 집계 기준을 '1보다 큰 값'으로 바꿔 준다면 중복 값만 죽 출력해 리스트로 얻을 수 있겠다.

SELECT 주문번호

               , COUNT(주문번호) AS 중복체크 FROM order_list
GROUP BY 주문번호
HAVING COUNT(주문번호) > 1;

중복 데이터가 몇 개 없다면 지워버리면 그만이겠지만, 과하게 발생하고 있다면 컴퓨터의 실수보단 내 실수일 가능성이 크다. 이런 상황에서는 전체 컬럼을 띄워 놓고 데이터 사이의 접점을 체크해보면 되겠다. HAVING을 단순히 조건 집계용으로 사용하는 방식이다. 쿼리와 표를 마지막으로 보여주며 마무리한다.

SELECT 주문번호, 고객ID, 주문일자, 배송ID

               , COUNT(주문번호) AS 중복체크 FROM order_list
GROUP BY 주문번호, 고객ID, 주문일자, 배송ID
HAVING COUNT(주문번호) > 1;

참고

learnsql 홈페이지