※ 일본의 한 블로그 글을 번역한 포스트입니다. 오역 및 직역, 의역이 있을 수 있으며 틀린 내용은 지적해주시면 감사하겠습니다.
전제
유저 ID | 이름 | 메일주소 | 작성한 포스트 수 | 받은 좋아요 수 |
1 | 홍길동 | example1@example.com | 10 | 5000 |
2 | 김철수 | example2@example.com | 1 | 7 |
3 | 이영희 | example3@example.com | 3709 | 6446131 |
다음과 같이 데이터를 추출하려고 한다고 가정하자. 테이블의 유저 ID는 프라이머리 키, 이름이나 메일 주소는 프라이머리 키와 동일한 users 테이블의 필드에 존재하는 정보라고 생각하게 된다.
추출할 데이터가 users 테이블의 데이터뿐이라면 큰 문제는 아니다. 단순히 다음과 같은 select 문으로 하면 된다.
SELECT *
FROM users
WHERE act = 1
ORDER BY id DESC
그러나 백엔드 엔지니어가 이 테이블을 봤을 때 "아...."라고 하게 되는 포인트가 작성한 포스트 수 와 좋아요 수 항목이다. 이러한 존재로 인해 우리의 일이 두 배 혹은 세네배로 될지 모른다.
그러나 필요로 하는 이상, 구현해내야한다. 그러므로 위와 같이 데이터를 추출하려면 다음과 같이 작성해야 한다.
SELECT users.id, users.name, users.mail, COUNT(posts.id) AS post_number, COUNT(favorites.id) AS favorites_number
FROM users
LEFT JOIN posts
ON users.id = posts.user
LEFT JOIN favorites
ON users.id = favorites.user
WHERE users.act = 1
AND posts.act = 1
GROUP BY users.id
ORDER BY users.id DESC
말이 길어졌지만, 이번 포스팅에서는 결국 이 SQL중 집계 처리를 실현하는 "GROUP BY"문구에 대해서 이야기하고자 한다.
GROUP BY와 집계함수
GROUP BY를 사용할 때 는 어떨 때일까? 이것은 원하는 데이터가 하나의 데이터가 아닌 여러 개의 데이터를 모아서 계산 결과도 포함하고 싶을 때이다.
SQL에는 다양한 "집계 함수"라고 불리는 것들이 존재한다. 예를 들면 COUNT이다. 그 외에도 최대값과 최소값을 반환하는 MAX, MIN, 합계를 반환하는 SUM과 평균을 반환하는 AVG가 자주 사용되는 집계함수이다.
이러한 것들은 여러 개의 데이터를 정리해 하나의 값으로 반환해준다. 방금 봤던 SQL을 다시 살펴보자.
SELECT users.id, users.name, users.mail, COUNT(posts.id) AS post_number, COUNT(favorites.id) AS favorites_number
FROM users
LEFT JOIN posts
ON users.id = posts.user
LEFT JOIN favorites
ON users.id = favorites.user
WHERE users.act = 1
AND posts.act = 1
GROUP BY users.id
ORDER BY users.id DESC
users 테이블 외에도 posts, favorites 데이터블이 LEFT JOIN으로 결합되어 있으므로, 보통이면 users 테이블의 레코드와 관련된 posts * favorites 테이블의 수 중복되게 된다.
users.id | users.name | users.mail | posts.id | favorites.id |
1 | 홍길동 | example1@example.com | 1 | 1 |
1 | 홍길동 | example1@example.com | 1 | 2 |
1 | 홍길동 | example1@example.com | 2 | 3 |
1 | 홍길동 | example1@example.com | 2 | 4 |
2 | 김철수 | example2@example.com | 2 | 3 |
... | ... | ... | ... | ... |
그러나 이 SQL에는 GROUT BY users.id 이라는 한 줄이 존재한다. 이것은 users.id마다 엮은 정보를 1개 레코드로서 반환된다는 의미로, 이 SQL이 반환하는 레코드는 users.id으로 중복되는 것은 없어진다.
users.name, users.mail은 users.id 와 동일한 테이블에 있는 필드이므로 문제없이 획득가능하다. 반면, posts, favorites 테이블은 하나의 레코드에 여러 개의 데이터가 섞여 있는 상태가 된다.
users.id | users.name | users.mail | posts.id | favorites.id |
1 | 홍길동 | example1@example.com | 1,2 | 1, 2, 3, 4 |
2 | 김철수 | example2@example.com | 3, 4 | 5, 6, 7, 8, 9, 10 |
3 | 이영희 | example3@example.com | NULL | NULL |
예로 아래의 SQL은 에러가 된다. users.id로 그룹화해버리면 posts.id나 favorites.id는 여러 개의 데이터가 해당될 가능성이 있어, SQL은 어떤 것을 반환할지 모르게 되어버리기 때문이다.
SELECT users.id, users.name, users.mail, posts.id, favorites.id
FROM users
LEFT JOIN posts
ON users.id = posts.user
LEFT JOIN favorites
ON users.id = favorites.user
WHERE users.act = 1
AND posts.act = 1
GROUP BY users.id
ORDER BY users.id DESC
그러므로, users.id와 일 대 일이 되지 않은, 이 경우는 posts 테이블과 favorite 테이블의 결과는 집계 함수로 묶을 필요가 있다.
SELECT users.id, users.name, users.mail, COUNT(posts.id) AS post_number, COUNT(favorites.id) AS favorites_number
FROM users
LEFT JOIN posts
ON users.id = posts.user
LEFT JOIN favorites
ON users.id = favorites.user
WHERE users.act = 1
AND posts.act = 1
GROUP BY users.id
ORDER BY users.id DESC
users.id | users.name | users.mail | COUNT(posts.id) | COUNT(favorites.id) |
1 | 홍길동 | example1@example.com | 2 | 4 |
2 | 김철수 | example2@example.com | 2 | 6 |
3 | 이영희 | example3@example.com | 0 | 0 |
GROUP BY와 집계함수는 끊어도 끊을 수 없는 관계이다. GROUP BY를 사용하여 에러가 발생해버리는 경우는 맨 처음에 쓴 SELECT 구문에 적힌 필드를 의심해 볼 필요가 있다. 문제가 발생하는 부분은 집계 함수를 사용해야하는데 본연의 필드를 획득하고 있으려고 하는 경우가 대부분이다.
GROUP BY와 HAVING
집계 함수 이외에도 GROUP BY와 관계가 깊은 것이 있다. 그것은 바로 HAVING이다. HAVING은 GROUP BY없이는 성립되지 않는 구문이다.
SELECT users.id, users.name, users.mail, COUNT(posts.id) AS post_number, COUNT(favorites.id) AS favorites_number
FROM users
LEFT JOIN posts
ON users.id = posts.user
LEFT JOIN favorites
ON users.id = favorites.user
WHERE users.act = 1
AND posts.act = 1
GROUP BY users.id
HAVING COUNT(favorites.id) > 100
ORDER BY users.id DESC
위 SQL은 무정하게도 받은 좋아요 수가 100 이하인 유저를 결과에서 가져온 것이다. 이 구문으로 본다면 HAVING은 WHERE과 비슷한 기능을 가진 것 처럼 보인다.
그럼 왜 WHERE이 아닌 HAVING을 사용할 필요가 있는 것일까? 이에 대한 대답은 SQL이 실행되는 순서에 있다. SQL은 작성된 순서가 아닌 다음과 같은 순서로 실행된다.
- FROM
- ON
- JOIN
- WHERE
- GROUP BY
- WITH CUBE 혹은 WITH ROLLUP
- HAVING
- SELECT
- DISTINCT
- ORDER BY
- TOP
WHERE은 GROUP BY보다 전에 실행되고, HAVING은 뒤에 실행되는 것을 알 수 있다. 즉, 집계 함수를 사용하여 얻어진 정보는 GROUP BY에 의해 얻어지므로, 그 정보에 조건에 따른 데이터를 획득하고 싶다면 WHERE 의 타이밍이 아닌 HAVING으로 해야한다.
GROUP BY와 ORDER BY
지금까지 다양한 포스트에서 소개되어 있지만, 실무에서는 GROUP BY와 ODER BY를 합쳐서 사용하는 경우가 빈번하다.
여기에서 주의해야할 부분은 SELECT 구문에 지정할 수 없는 정보는 ORDER BY 구문으로도 지정할 수 없다는 점이다.
예를 들어 아래의 예는 실패하게 된다. SELECT 구문에서 사용할 수 없는 posts.id로 sort하려고 하고 있기 때문이다.
SELECT users.id, users.name, users.mail, COUNT(posts.id) AS post_number, COUNT(favorites.id) AS favorites_number
FROM users
LEFT JOIN posts
ON users.id = posts.user
LEFT JOIN favorites
ON users.id = favorites.user
WHERE users.act = 1
AND posts.act = 1
GROUP BY users.id
ORDER BY posts.id DESC
이 SQL을 보면, 제일 처음 포스트를 쓴 사람 순으로 나열하고 싶다는 것을 의미하는 듯 하다. 어디까지나 원하는대로 제대로 SQL를 쓴다면 다음과 같이 된다.
SELECT users.id, users.name, users.mail, COUNT(posts.id) AS post_number, COUNT(favorites.id) AS favorites_number
FROM users
LEFT JOIN posts
ON users.id = posts.user
LEFT JOIN favorites
ON users.id = favorites.user
WHERE users.act = 1
AND posts.act = 1
GROUP BY users.id
ORDER BY MAX(posts.id) DESC
대개의 경우, posts.id는 AUTO_INCREMENT설정에 따라 정 방향으로 늘어난다.
ORDER BY에 집계 함수를 사용사용하는 것은 위화감을 느낄지도 모르겠지만, 유저에 따른 최신 포스트는 posts.id가 최대의 포스트인 것을 의미하므로 MAX(posts.id)으로 정렬하는 것이 실제에 근접한 접근 방식이다.
GROUP BY 와 DISTINCT
마지막으로 GROUP BY와 비슷한 동작을 하는 DISTINCT와의 사용법 구문에 대해 설명하도록 하겠다.
아래의 SQL는 "삭제되지 않은 포스트를 최소 하나는 썼지만, users 테이블의 정보 밖에 필요 없다"는 경우를 상정하여 필자가 쓴 것이다.
SELECT DISTINCT users.id, users.name, users.mail
FROM users
INNER JOIN posts
ON users.id = posts.user
WHERE users.act = 1
AND posts.act = 1
ORDER BY users.id DESC
필요한 것은 users 테이블의 정보뿐이지만, 엮는 조건으로 posts 테이블의 정보가 필요하므로 INNER JOIN으로 결합하고 있다.
하지만, 이대로는 결과가 중복되므로 DISTINCT를 사용하고 있다. 그러나 동일 결과는 아래와 같이 GROUP BY로도 획득 할 수 있다.
SELECT users.id, users.name, users.mail
FROM users
INNER JOIN posts
ON users.id = posts.user
WHERE users.act = 1
AND posts.act = 1
GROUP BY users.id
ORDER BY users.id DESC
어느쪽이 더 좋은지는 경우에 따라 다르다.
필자로서는 '중복행을 배제한다'는 본래의 목적과 부합하는 DISTINCT를 사용하는 것이 더 좋지만, 한편으로는 GROUP BY를 이용하는 것이 더 빠른 경우도 있는 것 같다.
그다지 속도가 변하지 않는 경우는 DISTINCT를, 속도에 현저한 차이가 있는 경우나, 추후 「포스트를 두 개 이상 쓰고 있다」라고 하는 조건도 넣을 경우는 GROUP BY를 채용하는 등과 같이 필요에 따라 대응하면 된다.
참고자료
'IT > 기초 지식' 카테고리의 다른 글
[SQL] UNION과 UNION ALL의 차이점 (0) | 2023.04.11 |
---|---|
[PostgresSQL] PostgresSQL에서 잘 알려지지 않은 형태 세 가지 (0) | 2023.04.10 |
[Jest] 프론트엔드 테스트에서 비동기 처리 다루기 (0) | 2023.03.23 |
TDD(Test Driven Development) (0) | 2023.03.21 |
[DDD] DDD를 실천하기 위한 안내서 (개념/도입편) (1) | 2023.03.18 |