테이블 확장 시점?

Question

테이블을 처음 설계할 때 어느 정도의 확장성을 지녀야할 지 모르겠습니다...예를 들어서 기획자가, 회원 간의 리뷰를 만들어 달라고 했습니다.from_member_idto_member_idcomment여기서 기획자는 다른 종류의 리뷰가 생길지는 아직까지는 잘 모르겠다. 라고 합니다.이때,이후에 생기게 될 다른 종류의 review를 고려하지 않고 테이블을 설계를 하는 것이 맞을까요?<생각한 선택지>이후에 생길 수도 있는 다른 종류의 review를 고려하지 않고 테이블을 설계한다.처음 생성 : from_member_idto_member_idcomment=> 이때, 다른 종류의 review가 생긴다면 업데이트 할 때 서버를 멈춘다. 그 후, review 를 부모 테이블로 만들고 member_review, item_review 테이블로 자식 테이블을 만든다. 그 후, 부모-자식 테이블로 합치기.다른 종류의 review를 고려한다.처음 생성 : from_member_idto_member_idcomment=> 이때, 다른 종류의 review가 생긴다면 item_review, movie_review.. 등등으로 만들어서 member_review, item_review 등등 각기 서로 연관 없이 고유 테이블로 사용이런 식으로 생각이 드는데 어떤 방법을 생각해야할까요?? 아니면 이것보다 더 나은 방안이 있을까요?

catcode · Accepted Answer

리뷰테이블 안에 리뷰종류구분코드 컬럼을 추가해서 관리하는 방법도 있습니다.

rockbach · Answer

기획도 모르는 생길지 모를 미래의 일을 예상하고 만드는것은 좀 애매하군요. 저라면 꼭 지금단계에서 결정해야 한다면 review_type 컬럼 하나 추가해 놓고 없으면 기본 리뷰, 값이 있으면 해당 타입의 리뷰로 보겠습니다. 코딩량도 줄일수 있고 나중에 type으로 필터링해서 분리도 가능하며 통합 검색등에 용이합니다.

김수9637 · Answer

답변 모두 감사합니다!이해한 내용으로는 review 단일 테이블에서 type 구분 필드 1개를 두자. 라는 것으로 이해했습니다.그렇다면 나중에 리뷰 종류가 늘어나더라도 review 단일테이블에서 fk 필드만 여러개 만들어서 관리하는 건가요??이렇게 됐을때 fk가 계속 증식하는 단점이 있을텐데 부모 자식 테이블(review - member_review, item_review)와 같은 구조는 포기하는 이유가 있을까요?

테이블 확장 시점?

3개의 답변

#db 목록