마지막프로젝트를 시작했다. 이번 프로젝트에선 부리더를 맡아 진행했다. 4번의 프로젝트를 경험해서 그런건지.. 아니면 3계층을 직접 나눠봄으로써 express 의 이해도가 높아져서 그런진 몰라도 API 명세서를 직접 작성하며 코드가 그려지고, ERD 를 보며 예전에 이해 안되는 부분들이 이해가 가기 시작했다.
auth API 묶어주기
로그인, 회원가입, 이메일찾기, 비밀번호 찾기 url 을 따로 분리했었는데 auth 로 통합하라는 피드백을 받고 같이 묶어주었다. 전체적인 통일성을 유지하면 좋다고 한다.
API 메서드 PUT 과 PATCH
이번 API 를 작성하며 PUT 과 PATCH 를 제대로 알게 된 계기가 됐다. API 명세를 작성하기 전 PUT 은 전체를 바꿀때, PATCH 는 부분적으로 바꿀 때 사용한다고만 알고 명세서를 작성할려 하니 복잡한 부분이 있어서 제대로 알아보게 됐다.
PUT 은 정의된 데이터를 넣지 않으면 정의하지 않은 데이터는 null 로 자동 수정 되고, 만약 새로운 데이터를 넣었을 때, 새로 생성된다.
PATCH 는 정의된 데이터를 넣지 않으면 새롭게 넣은 데이터만 수정되며, 정의된 데이터는 변화가 없다. 만약 새로운 데이터를 넣을려 한다면, 오류를 반환한다.
우리 프로젝트에선 수정 API 를 주로 작성했기 때문에, PUT을 쓸 일은 없었다.
데이터베이스 관계
1:1,1:N , M:N, Mapping 테이블 이해
1:1
User 테이블과 address 테이블은 한개씩 참조할 수 있다. 잘 사용되지 않음
1:N
참조되는 테이블의 한 row 가 참조하는 테이블의 여러 row (entity객체) 를 가질 수 있다.
N:M 관계
양쪽 테이블 모두 1:N 관계를 가지는 것, 이 경우 가운데 매핑 테이블을 따로 만들어서 두 테이블의 FK 를 넣어 양쪽을 1:N 관계로 만들어준다.
헷깔렸던건 WishLists , Users 의 관계였는데 Users는 WishLists 를 한개만 가지고 있으니 1:1 관계가 아닌가에 대한 고민을 했다. 하지만 이건 바구니라고 생각해서 나오는 결론이였고, 유저가 파티를 한 개씩 찜할 때마다 row가 한 개씩 쌓이니 1:N 관계라 하였다. 이 부분은 좀더 찾아보고 고민해봐야 할 문제같다.
기본 용어
entity : 데이터베이스에 입력될 데이터의 집합 (테이블)
entity 객체 : 테이블의 row
관계명 : 엔티티가 관계에 참여하는 형태를 지칭, 하나의 관계는 2개의 현재형으로 표현(포함한다, 소속된다)
관계차수 : 1:1, 1:N N:M 이런거
관계 선택 사양 : 관계에 항상 참여 or 관계에 선택 참여
key : 테이블의 특정 row(record, tuple) 을 식별, 다른 테이블의 특정 row를 참조할 때 사용(PK 와 FK가 있다.)
Primary Key(PK) : 특정 row 를 식별하기 위해 사용
Foreign Key(FK) : 다른 테이블과 연결하는데 사용
