-
12/ 28스파르타/TIL(Today I Learned) 2023. 12. 28. 09:22
프로그래머스 _ 조건에 맞는 사용자와 총 거래금액 조회하기 (41번 문제)
-- 완료된 거래 금액이 70만원 이상, SELECT u.user_id , u.nickname, sum(b.price) PRICE from used_goods_board b inner join used_goods_user u on b.WRITER_ID = u.USER_ID group by u.user_id having sum(b.price) >= 700000 and b.status = 'DONE' order by 3 asc
위에는 처음에 내가 생각해낸 코드이다.
where절을 없애고 having절에 모든 것을 썼다.
하지만 오류가 발생했다.
Unknown column 'b.status' in 'having clause'
b.status가 문제였다.
그래서 아래행처럼 문제가 되는 행만 where절에 사용하니 잘 작동하였다.
-- 완료된 거래 금액이 70만원 이상, SELECT u.user_id , u.nickname, sum(b.price) PRICE from used_goods_board b inner join used_goods_user u on b.WRITER_ID = u.USER_ID where b.status = 'DONE' group by u.user_id having sum(b.price) >= 700000 order by 3 asc
문제의 원인을 알아보던 중
having이라는 것은 결국 group by로 묶은 그룹에 대한 조건 식이며
내가 쓰려고 했던 b.status는 개별 행이라서 두개가 충돌하면서 오류가 발생하였다.
https://school.programmers.co.kr/learn/courses/30/lessons/164668
즐겨찾기가 가장 많은 식당 정보 출력하기
-- 음식종류로 묶기, 즐찾 많은 순 SELECT food_type,rest_id,rest_name,favorites from rest_info where favorites in (select max(favorites) from rest_info group by food_type) group by food_type #having max(favorites) order by 1 desc # having은 안되고 where이 되는 이유
해당 문제를 풀면서 having절을 사용해서 코드를 돌리니 정답이 아니라고 나왔다.
내 생각으로는 그룹화 된 food_type별로 max(favorites)을 사용하여 쿼리를 돌리면
될거라고 생각했지만 아니였다.
일단. 튜터님에게 물어보니 실무에서는 where을 더 많이 쓰고
서브쿼리나 with절을 사용하여 임시 테이블을 만들어 사용하는 방법이 더 좋다고 한다.
나도 이제부터 최대한 where절을 사용해 보겠다.
튜터님의 답변 : 그룹화 하지않고 정렬만 해도 되어서 말씀하신대로 where절에 조건 걸어주면 됩니다!
SELECT food_type, rest_id, rest_name, favorites FROM rest_info WHERE (food_type, favorites) IN ( SELECT food_type, MAX(favorites) AS max_favorites FROM rest_info GROUP BY food_type) order by 1 desc
튜터님이 보내주신 코드이다. 메인 쿼리에 그룹화를 하는 것이 아닌 조건에 필요한 데이터만 서브쿼리 안에서 그룹화,집계 함수로 처리하여
메인 쿼리를 더 간단하게 하였다.
본론으로 돌아와서 왜 having은 안되고 where이 되는 이유 ?에 대한 검색을 많이 해본 결과
현재 그룹화 된 데이터에 대하여 한개의 행인 favorites에 대한 조건을 걸어야 하는 상황이다.
이는 개별 행에 대한 조건이므로 where절에 쓰는 것이 맞다고 한다.
https://school.programmers.co.kr/learn/courses/30/lessons/131123#qna
SQLD 강의 3주차를 들으면서 가장 헷갈리는 부분이 ERD, 표기법에 따른 차이점였다.
과거 공부할 때 EDR에서 관계를 나타낸 관계의 페어링부분이 가장 어려웠다.
이유는 여러개의 엔터티가 나오는 순간 복잡해지기 때문이다
강의에서는 ID, Barker 표기법에 대한 내용을 알려주었고 실제로 관계 차수를 자세히 다뤘다.
특히 위의 표와 같이 해석을 표로 정리하여 이해를 쉽게 해주었다.
속성과 엔터티는 이해하기 쉬웠지만 이 부분은 헷갈리는 부분이 많아 조금 어렵게 느껴졌다.
정규화는 데이터를 쪼개는 것이라고 생각하면 쉽고
데이터가 쪼개져있지 않고 뭉쳐있으면 하나만 잘못되어도 다 꼬이고
원하는 데이터를 찾기 위해서도 시간이 많이 걸린다.
우리는 데이터를 효율적으로 관리하고 조작하고 싶기 때문에 정규화가 필요하다.
우리가 알아야 할 정규화는 3단계가 있다.
정규화들을 안해주면 이상현상이 발생하기 때문에 정규화를 해주는것이 좋다.
무조건 정규화가 좋은것인가?에 대한 답은 아니다.