JOIN

JOIN서로 다른 데이터 테이블을 연결하는 것테이블 내의 데이터를 연결할 수 있는 공통 값이 있어야 함.위 같은 상황에선 트레이너 데이터에 pokemon_id를 추가하거나 포켓몬 데이터에 trainer_id를 추가해야 join이 가능하다 아니면 위와 같은 테이블을 하나 만들어 각각 join을 하면 가능하다JOIN을 하기 위해선 key를 기준으로 한다. 보통 xx_id로 설정 Why JOIN?정규화 과정을 통해 데이터의 중복을 최소화한다.이때 User Table에선 User 데이터만, Order Table에선 order 데이터만 저장.때문에 공통된 칼럼을 찾기 위해선 JOIN 필요 (JSON 같은 NOSQL 기반에서는 불필요)SQL JOININNER JOIN LEFT (OUTER) JOINRIGHT JOINFULL (OUTER) JOINCROSS JOINJOIN 작성 요령하려는 작업의 목적에 맞춰 JOIN 선택교집합 : INNER모든 조합: CROSS이외: LEFT or RIGHT, 주로 LEFT를 선택LEFT는 기준에 기준값이 있으며 우측으로 데이터를 추가하는 방식이다.보기 편함

리팩토링

리팩토링?소프트웨어의 유지보수와 생산성 향상을 위해 기능의 변화 없이 코드를 수정, 보완하는 기법주로 프로젝트를 마무리 한 후 진행하는 단계이다원인중복된 코드지나치게 긴 메소드클래스 하나로 많은 작업 처리클래스 역할 불충분필요 없는 작업 처리하는 코드잘못된 클래스 상속 구조etc기대효과설계의 질 향상이해도 및 가독성 향상 -> 버그 찾기 용이함개발 속도 향상기법메소드 추출클래스 추출메소드 이름 변경가독성, 유지보수에 도움 풀업 메소드성공적인 리팩토링 기준소규모로 나눈다회귀테스트 성공 작동 성공

DBMS LOCK

Lock 이란?데이터베이스는 기본적으로 어려 유저가 사용하는 시스템으로써, 동시에 접근하는 경우가 많다. 저장된 데이터는 일관성, 무결성을 유지해야 하며, 동시에 접근하는 상황에서는 특별한 조치가 필요하다.예를 들어 콘서트 자리가 하나 남았는데 2명의 유저가 동시에 티켓팅을 할 경우 티켓팅 성공은 한 사람만 이뤄져야 한다. 이 특별한 조치를 DBMS에서 사용하는 방법이 바로 lock(잠금) 이다.즉, lock은 순차적인 접근을 위한 조치라고 볼 수 있다.Lock의 종류공유 잠금(Shared lock)a.k.a. 읽기 잠금배타 잠금(Exclusive lock)a.k.a 쓰기 잠금공유 잠금(Shared lock)데이터를 읽을 때 사용하는 잠금공유 잠금끼리 접근 가능공유 잠금이 설정된 데이터에는 배타 잠금 사용 불가즉, 공유 잠금이 설정된 경우 다른 세션이 동일한 데이터를 읽을 수 있지만 수정은 불가능배타 잠금(Exclusive lock)데이터 변경할 때 사용하는 잠금트렌젝션 완료까지 유지됨 잠금 해제하기 전까진 다른 트렌젝션 접근 불가즉 배타 잠금 설정 시 다른 세션이 동일한 데이터를 읽을 수도 없으며 수정 또한 불가능블로킹(Blocking)잠금들의 경합으로 인해 특정 세션이 작업을 진행하지 못하고 멈춘 상태공유 잠금 배타 잠금 / 배타 잠금 배타 잠금 간 발생 가능해결 방법으로는 이전 트렌젝션이 완료(commit or rollback)돼야 한다.기본적으로 발생 시 먼저 잠금 설정한 트렌젝션을 기다려야 한다. 반복 시 성능 저하 야기 가능하여, 최소화하는 작업이 필요최소화 방법SQL문을 리팩토링하여 빠르게 실행되게 한다.트렌젝션을 짧게 정의동일한 데이터를 변경하는 트렌젝션이 동시에 수행되지 않도록 방지트렌젝션이 활발한 주간에는 대용량 갱신 작업 X필수불가결 상황일 시, 트렌젝션 작업 단위를 나누거나 lock_timeout을 설정하여 최대 잠금 시간 설정교착 상태(Deadlock)여러 개의 트랜젝션들이 자신의 작업을 실행하지 못하고 상대의 작업이 끝나기를 무한정 기다리는 상태를 교착 상태라 한다. 해당 상태는 대표적인 lock의 부작용 사례라고 볼 수 있다. 위의 사진은 교착상태가 일어난 상황이다. 트렌젝션 A는 game_master 테이블의 2번 row를 변경한 후 game_detail의 2번 row를 변경하고자 한다. 반면 트렌젝션 B는 game_detail의 2번 row를 변경한 후 game_master의 2번 row를 변경하고자 한다. 이 상황에서 트렌젝션 A는 game_master의 2번 row에 lock을 걸었으며, 트렌젝션 B는 game_detail의 2번 row에 lock을 걸었다. 트렌젝션 A는 game_detail의 2번 row의 잠금이 풀릴 때 까지 대기해야 하며, 트렌젝션 B는 game_master의 2번 row의 잠금이 풀릴 때 까지 기다려야 한다.이때 서로가 먼저 끝나지 않으면 무한정 대기 상태에 빠지게 되며, 이게 바로 교착 상태(Deadlock)이다. 해결 방법트렌젝션 방향을 같게 설정한다.위의 사례를 예시로 보면, 트렌젝션 A의 접근 순서는 game_master -> game_detail이며, 트렌젝션 B의 순서는 game_detail -> game_master이다. 이때, 트렌젝션 B의 순서를 game_master -> game_detail로 바꿀 시, 교착 상태를 방지할 수 있다. 비록 이러한 상황에서는 블로킹 현상이 발생할 수 있지만, 교착 상태와 비교해서는 감안할 만한 문제이다. 트렌젝션 처리 속도 최소화 set_lock_timeout을 사용하여 잠금 해체 시간 조절무한정 대기에 빠지는 것을 방지한다출처데이터베이스 교착 상태(Dead Lock) : 네이버 블로그 (naver.com)[데이터베이스] 잠금이란? (tistory.com)