테이블 간의 관계?
BOOK, AUTHOR, BOOK_SALES 테이블이 있다
나는 아래와 같이 썼는데
select b.AUTHOR_ID, a.AUTHOR_NAME, b.CATEGORY, (b.PRICE * a.SALES)as SALE
FROM BOOK b
JOIN BOOK_SALES bs ON b.BOOK_ID = bs.BOOK_ID
JOIN AUTHOR a ON b.AUTHOR_ID = a.AUTHOR_ID
WHERE date_format(SALE_DATE, '%Y'-'%m') = 2022-01
GROUP BY b.AUTHOR_ID, b.CATEGORY
ORDER BY b.AUTHOR_ID ASC, b.CATEGORY DESC서브쿼리와 WITH 절
서브쿼리라는 게 있는데 가독성이 좋지 않다. MySQL 8 이후로는 WITH 절을 쓰는게 좋다. 임시테이블을 정의해주고, 쿼리에서 마치 테이블처럼 사용할 수 있게 해주는 기능이다.
게임을 만들다 보면 우리 게임에 대한 통계를 내야 할 때가 있다. 접속시간, 리텐션, BM 등등 여러가지에 대한 자료를 뽑아볼 필요가 있는 순간이 온다. 게임은 센트리, 웹에선 구글 애널리스틱스 등 여러가지 툴들이 있다.
-> WITH절로 만들어지는 임시테이블은 마치 실존하는 테이블처럼 쿼리에서 쓸 수 있다.
WITH 임시테이블 이름 AS (
SELECT
)UNION ALL
두 테이블의 모든 데이터를 합쳐주는 구문이 UNION ALL이다.
어렵게 WITH절 쓰지 말고 어플리케이션 레벨에서 쿼리를 나눠서 쓰면 안되나?
서비스를 할때 일반적으로 DB와 서버는 같은 곳에 있지 않다. 물리적으로 분리되어 있기 때문에 네트워크를 타고 가져와야 한다. 그렇기 때문에 WITH절을 쓰지 않고 어플리케이션 레벨의 쿼리를 나눠서 쓰게 되면, 네트워크를 여러번 타고 DB도 여러번 일 시키게 되는 셈.
-> 그래서 네트워크 레이턴시와 DB 메모리 부하가 늘어나게 된다.
-> 그리고 억까이긴 하지만 앞쿼리와 뒷쿼리 수행 사이에 앞쿼리의 결과에 새로운 데이터가 저장된다면, 뒷쿼리는 옛날 데이터를 담은 채로 돌아가게 되어 데이터의 일관성이 깨지게 될 수도 있다.
-> DB를 쓰는 순간 DB에서 모든 쿼리를 처리하고 가는 것이 베스트다. 서버는 생각보다 굉장히 바쁘기 때문에 부하를 안 줄 수 있으면 안 주는 것이 좋다. DB와 일을 나눠서 하자.
날짜간의 차이는 DATEDIFF(return_date, due_date) 로 알 수 있다.
각 도서에 대해 연체된 대여 건수를 계산하고 연체된 도서만 평균 연체일수 계산
