카테캠 : 1주차 코드리뷰

내가 작성한 코드에 대해 리뷰를 받는 시간을 가졌다.

꼼꼼하게 리뷰해주셔서 너무 감사하다 😊

 

Q&A

Q1.  데이터 타입의 범위

데이터베이스 설계시 데이터 타입의 범위를 어느정도 설정해야 좋을지 궁금합니다.
50글자의 글을 저장할때, 여유를 두고 varchar(200)을 할지, varchar(500)을 하는 것이 좋은지
그 범위의 정도가 궁금합니다.

실무에서는 데이터베이스 설계하는 분과 함께 의논한다고 하셨는데, 어느정도까지 개발자가 임의로 결정해야하는지 궁금합니다.🤔

 

Answer

데이터의 범위에 정답은 없다고 생각합니다. 해당 테이블이 어떤 도메인에서 어떠한 데이터를 저장하는 컬럼인지 생각해보고
예상되는 데이터 범위를 생각하여 지정을 하고 있습니다.

DBA분과도 얘기를 나누지만 개발단계에서 도메인에 대한 부분은 개발자가 더 많이 이해하고 있을수 있습니다.
개발자가 생각하는 데이터 범위를 정하고 DBA분과 얘기할때 컬럼의 성격과 도메인에 대한 설명을 가지고 얘기를 하며
조율해서 맞춰갑니다.

 

Q2. 외래키 vs 인덱스

제가 작성한 테이블은 인덱스를 사용하지 않고 외래키를 사용해서만 연관관계를 맺어주었습니다.
이렇게 작성한 이유는 평소에 외래키를 사용해왔기 때문입니다.

하지만 좀 더 공부해보니 실무에서는 외래키를 사용하는 것을 그리 좋아하지 않는다❕는 이야기를 들었습니다.
외래키를 이용하면 무결성을 보장할 수 있지만, 오버헤드와 고려할 점이 많이 생기기 때문입니다.

멘토님이 만약 카카오 쇼핑하기 서비스를 개발하신다면,
외래키를 사용하고 싶으신지, 인덱스를 사용해서 DB 설계를 하고 싶으신지 궁금합니다.
그리고 정말 실무에서 외래키보다 인덱스를 더 사용하는지에 대해
멘토님의 생각이 궁금합니다. 😁

 

Answer

제가 만약 카카오 쇼핑하기를 개발한다면 외래키를 사용 안하고 설계를 하고 싶습니다.
말씀하신대로 FK가 맺어져 있다면 데이터 추가, 삭제시 제약사항이 생기는 등의 불편함등이 있어서
실무에서도 FK는 사용하지 않고 인덱스를 사용하고 있습니다.

 

코드 리뷰 해주신 사항

Restful한 설계

RESTful 하다 = URI만 보더라도 리소스를 파악할 수 있다. HTTP 메서드를 이용하여 각 리소스 기능을 일관되게 정의한다.

출처: https://velog.io/@joshuara7235/RESTful-%ED%95%98%EB%8B%A4

RESTful 하다는게 뭐야?

 

/carts/add와 /carts/update 각각 url로 정의하여 post하는 것보다,

POST - /carts >장바구니 저장
PUT - /carts/{cartId} > 장바구니 수정
GET - /carts/{cartId} > 장바구니 조회

로 정의하여 같은 엔드포인트를 HTTP 메서드를 사용해 제어하는 것이 Restful하다.

 

+ 객체명을 사용할때 복수명을 사용하면 더욱 Restful하다고 한다.

 

요구사항 vs 구현

배달 관련된 내용이 요구사항에 존재하지 않아서 테이블을 작성하지 않았는데,

요구사항에 없더라도 실제로 필요한 데이터라면 받아야한다고 하셨다.

맞다..!! 돌아가는 것이 1차 목적이므로 요구사항은 충분히 추가할 수 있다!

 

아이디 데이터 범위

아이디를 정의할때 테이블 컬럼 타입을 INT(11)로 설정했다.

그 이유는 INT는 INT(11)과 같은데, 원래는 10자리이지만 음수를 표현하기 위해(-) 11자리가 default이다.

그런데 아이디는 계속 증가되게 부여된다. 즉 양수이므로, 10자리만 필요하다..!!!!!!!(unsigned int도 10자리만 필요)

 

❕ 이러한 고민 사항이 어떤 도메인에서 어떤 데이터를 넣을지 생각하며 데이터 범위을 결정하는 구나의 예시인 것 같다.

그런데 만약 실무에 들어간다면 INT가 아닌 bigint를 사용할 것이므로 더이상의 고민은 안하기로 했다.!

 

외래키 ON UPDATE 제약조건

Q. 장바구니에 price가 있는 경우 옵션의 가격 정보가 바뀌면 어떻게 해야할까요?

 

A.

cart 테이블은 option_id를 외래키로 참조하고 있는데, ON UPDATE 제약조건을 사용하지 않으므로 NO ACTION이 수행됩니다.

NO ACTION은 MySQL에서 RESTRICT와 같으며, 참조하는 객체가 존재한다면 변경 작업이 취소됩니다.

option_id는 option 테이블에서 변경되지 않는 값이므로, 신경쓰지 않아도 됩니다.

✳️ option table의 가격이 바뀐 후 해당 옵션이 장바구니에 담겨질 때, 다음과 같은 과정으로 price가 계산됩니다.

1. cart table은 참조하는 option_id를 이용해 옵션 테이블의 변경된 가격을 가져온다.
2. 변경된 옵션 가격을 반영하여 price를 계산한다.

ON UPDATE의 기본 옵션에 대해 생각해 볼 수 있었습니다. 감사합니다 !

 

 

멘토님이 과제 잘 진행하셨다고 해주셔서 너무 감사하다...

설계할때 많은 고민을 했는데, 그게 잘 드러났다는게 신기하고 다음주도 과제 열심히 해봐야겠다고 생각했다.