Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file added keyword/chapter01/image1.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added keyword/chapter01/image2.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
88 changes: 88 additions & 0 deletions keyword/chapter01/keyword.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,88 @@
- DB Join이란?

**Join** : 두 개 이상의 테이블을 엮어 하나의 결과 테이블로 만드는 것

하나의 테이블 만으로는 원하는 결과를 얻을 수 없는 경우, 두 개 이상의 테이블을 묶어서 원하는 결과를 얻기 위해 사용

- Join 종류들

**INNER JOIN** : ****기준 테이블과 JOIN 테이블의 교집합
JOIN 조건에 맞는 행을 출력

![image1.png](image1.png)

SELECT * FROM TableA A
INNER JOIN TableB B
ON A.key = B.key

---

**OUTER JOIN** : 기준 테이블의 행은 조건에 맞지 않아도 출력

LEFT, FULL, RIGHT OUTER JOIN이 있다.

![image2.png](image2.png)

위 사진처럼 같은 OUTER JOIN이더라도 WHERE 절의 조건에 따라 집합의 형태가 달라진다.

FULL OUTER JOIN은 성능/요구⬇️ 등의 문제로 거의 사용X → MySQL 도 지원 X
RIGHT OUTER JOIN도 테이블 순서만 바꾸면 LEFT OUTER JOIN과 결과가 동일 → 사용⬇️

---

**CROSS JOIN** : 한 쪽 테이블의 모든 행과 다른 쪽 테이블의 모든 행을 조합
⇒ Catesian Product, 경우의 수를 생성할 때 가장 많이 사용

---

**SELF JOIN** : 같은 테이블을 자기 자신과 JOIN

정해진 문법 없이, 같은 테이블을 조인하여 사용
같은 테이블 안에 있는 행과 행의 관계를 표현하기 위해 사용
(ex : 직원과 상사, 같은 점수의 학생, 더 비싼 상품 등)

참고자료

https://adjh54.tistory.com/155

https://innovation123.tistory.com/211

https://hongong.hanbit.co.kr/sql-%EA%B8%B0%EB%B3%B8-%EB%AC%B8%EB%B2%95-joininner-outer-cross-self-join/

https://yuna-story.tistory.com/164

- 트랜잭션이란?

**트랜잭션** : DB의 상태를 변화시키는 하나의 논리적 작업 단위
하나의 외부 거래를 기록하기 위해 시스템 내부에서 완료되어야 하는 일련의 처리 동작

**ACID 원칙**

**A**tomicity(원자성)
트랜잭션 내의 작업은 모두 반영되거나, 모두 취소되어야 함(롤백)

**C**onsistency(일관성, 정합성)
트랜잭션 완료 후 DB는 일관된 상태를 유지해야 함

**I**solation(고립성, 격리성, 독립성)
각 트랜잭션은 서로 간섭 없이 독립적으로 수행되어야 함

**D**urability(지속성, 내구성)
성공한 트랜잭션은 영구적으로 반영되어야 함

*A계좌 출금과 B계좌 입금이 대표적인 예시

참고자료
https://learn.microsoft.com/ko-kr/windows/win32/ktm/what-is-a-transaction

https://terms.tta.or.kr/dictionary/dictionaryView.do?word_seq=058427-1

- Join on 과 where의 차이점

ON : JOIN 시 두 테이블의 행을 결합하는 기준 → 행을 **붙일지 말지** 결정
특히 OUTER JOIN에서는 매칭 여부만 판단, 매칭X 인 기준 테이블의 행은 NULL과 함께 유지

WHERE : JOIN이 수행된 이후 결과를 필터링하는 조건 → 붙은 결과를 **남길지 말지** 결정
OUTER JOIN에 사용시 NULL이 포함된 행이 제거되어 결과가 INNER JOIN 처럼 변할 수 있음

INNER JOIN에서는 ON과 WHERE 모두 결과를 제한하는 역할이므로 대부분 동일한 결과가 나옴
125 changes: 125 additions & 0 deletions mission/chapter01/mission.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,125 @@
### 워크북 캡쳐

![week1_green.png](week1_green.png)

### 워크북 리뷰

<aside>
🌟

다른 챌린저들도 나도 위와 같은 기타 조인들에 대해서는 자세히 조사하지 않은 것 같다. 그린의 워크북 덕분에 조인의 개념에서 조건의 성격에 따라 어떻게 조인이 달라지는지 명확하게 짚고 넘어갈 수 있었다.

</aside>

======= 미션 =======

리뷰 작성하는 쿼리,
* 사진의 경우는 일단 배제

쿼리문

<aside>

사용자/가게의 ID를 1이라고 가정, 리뷰 id를 자동으로 1씩 증가하며 생성한다고 가정하면
review 테이블의 리뷰 내용, 평점, 사용자ID, 가게ID 속성을 지정한 값을 추가하는 쿼리가 필요하다.

INSERT INTO review (review_content, rating, user_id, store_id)
VALUES (”음 너무 맛있어요~~”, 5.0, 1, 1);

</aside>


마이 페이지 화면 쿼리

쿼리문

<aside>

사용자 테이블의 닉네임, 이메일, 휴대폰 번호, 현재 포인트 속성을 조회하는 쿼리가 필요하다.

SELECT nickname, user_email, user_number, current_point
FROM user
WHERE user_id = 1;

</aside>


홈 화면 쿼리
(현재 선택 된 지역에서 도전이 가능한 미션 목록, 페이징 포함)

쿼리문

<aside>

달성한 미션의 수를 계산해서 표시

SELECT COUNT(*)
FROM user_mission
WHERE user_id = 1;

---

현재 선택된 지역에서 도전이 가능한 미션 목록, 페이징

현재 선택된 지역 ‘안암동’의 지역 ID를 1이라고 가정
지역 ID가 1인 가게 ID를 찾고, 그 ID로 미션을 찾는다. 미션들을 현재 날짜를 기준으로 시작시점과 종료시점 사이에 있는 미션/활성화 되어있는 미션을 필터링하고, 그 결과에서 가게 이름, 미션 내용, 보상 포인트, 남은 기한을 보여준다.

SELECT s.store_name, m.mission_description, m.reward_point, m.end_at
FROM store s
JOIN mission m ON m.store_id = s.store_id
WHERE s.location_id = 1
AND CURRENT_DATE BETWEEN m.start_at AND m.end_at
AND m.is_active = 1;

위 SQL로 홈 화면에 필요한 정보를 찾을 수 있으나, 아직 페이징이 포함되어있지 않다.
가게 이름, 미션 내용, 보상 포인트, 종료 기한 만으론 미션을 유일하게 식별하기 어려울 수가 있다고 판단했고, 추가로 미션 ID를 조회해서 커서로 활용하도록 한다.

SELECT m.mission_id, s.store_name, m.mission_description, m.reward_point, m.end_at
FROM store s
JOIN mission m ON m.store_id = s.store_id
WHERE s.location_id = 1
AND CURRENT_DATE BETWEEN m.start_at AND m.end_at
AND m.is_active = 1
AND m.mission_id > ? #cursor
ORDER BY m.mission_id ASC
LIMIT 10;

</aside>

내가 진행중, 진행 완료한 미션 모아서 보는 쿼리(페이징 포함)

쿼리문

<aside>

내가 진행중, 진행 완료한 미션을 모아서 보상 포인트, 가게 이름, 미션 내용, 성공 여부를 조회해야 한다.

나의 사용자 ID를 1이라고 가정
사용자 ID가 1이면서 상태가 완료 혹은 미완료인 사용자 미션을 찾는다. 찾은 미션의 내용, 보상포인트를 조회하고, ID로 해당 미션에 맞는 가게를 찾는다.

SELECT m.reward_point, m.mission_description, um.status, s.store_name
FROM user_mission um
JOIN mission m ON m.mission_id = um.mission_id
JOIN store s ON m.store_id = s.store_id
WHERE um.user_id = 1
AND um.status IN (’COMPLETED’, ‘NOT_COMPLETED’);

마찬가지로 페이징을 위해 미션 ID를 추가로 조회하여 커서로 활용한다. 또, 완료 상태별로 묶어서 보이도록 ORDER BY stauts를 추가한다.

SELECT m.mission_id, m.reward_point, m.mission_description, um.status, s.store_name
FROM user_mission um
JOIN mission m ON m.mission_id = um.mission_id
JOIN store s ON m.store_id = s.store_id
WHERE um.user_id = 1
AND um.status IN (’COMPLETED’, ‘NOT_COMPLETED’)
AND (
um.status > ?
OR (um.status = ? AND m.mission_id > ?)
) #복합 커서
ORDER BY um.status ASC, m.mission_id ASC
LIMIT 10;

#복합 커서 → 현재 커서의 status보다 뒤에 오는 status이거나, status가 같다면 mission_id가 더 큰 것
status와 mission_id를 함께 커서로 사용해서 완료 상태별로 묶어서 페이징하도록 했다.

</aside>
Binary file added mission/chapter01/week1_green.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.