DB 설계와 구축을 직접 해보면서 이해를 다시 해보겠습니다.
저는 배달주문의 서비스를 선택해 보았습니다.
0. 서비스 개요
회원이 가게에서 주문을 한다.
회원만 자신의 위치를 기반(가입 시 설정한)으로 한 범위 내 가게에서 주문이 가능하다.(주문의 단위는 가게 하나와 1대 1 관계를 가진다)
회원은 가게에 대한 평점과 회원들의 리뷰들을 확인이 가능하다.
또한 회원은 자신의 주문내역을 확인 할 수 있고, 자신의 쓴 리뷰들만을 조회 가능하다.
1. 개념적 모델링
해당 서비스에 필요한 데이터 값들을 개념적 모델링을 통하여 표현해 보았습니다.
개념적 모델링 단계에서 디테일적인 부분을 생각하기보다는 어떤 값들이 필요할까? = 서비스의 요구사항 에 대해서 툭툭 던지면서 생각을 해보았습니다.
2. 논리적 모델링
member에 관한 논리적 모델링을 해보았습니다.
여기서 id(로그인 아이디)라는 값은 unique 하니까 pk로 아예 설정을 해보는 것은 어떨까 생각을 해보았습니다.
인조키와 자연키에 대한 고민.
https://hardworking-sloth.tistory.com/37
[DB] 인조키와 자연키
* 배달 시스템 DB 설계 포스팅을 예시로 하고 있습니다. 논리적 모델링 중 'member의 칼럼에 이미 unique 한 값(login_id)이 있는데, auto increment로 독립적인 P.K를 가져야 하는가'에 대해 고민해 보도록 하
hardworking-sloth.tistory.com
저는 인조키를 설정하기로 하였습니다. (특별한 언급이 없을 시 모든 테이블에 인조키를 두었습니다,)
이제 논리적인 모델링을 시작하는데 우선 1차 정규화에 위반되는 데이터들을 모두 쪼개 주었습니다.
이게 각 테이블에 대한 관계를 이어줘야합니다.
관계에 대한 정립 전, 생각해야 할 문제가 몇 발생하였습니다.
1. reviews
reviews 데이터에 대해 다시 생각해 보면,
a) member는 자신이 쓴 reviews에 대해서 조회가 가능함
b) store도 해당 store에 대한 reviews를 조회가 가능함
위 두 가지의 서비스를 가장 적합하게 해결해 주는 관계에 대해서 생각해야 함
- reviews라는 독립적인 table에 member와 store로 복합키 사용.
이는 한 가게에서 같은 member가 리뷰를 하나만 쓰는 것을 의미. > 원하는 방향 x
- reviews라는 독립적인 table 인조키를 사용.
조회에 있어서는 성능이 떨어지지만, 위 조건의 단점을 해결 가능.
-reviews를 member_reviews와 store_reviews로 쪼갬
데이터의 중복이 발생. 같은 리뷰의 내용을 두 번 저장.
-reviews라는 독립적인 table에 member와 created_time을 복합키로 사용.
복합키를 사용해보고 싶어서 일단 'reviews라는 독립적인 table에 member와 created_time을 복합키로 사용'을 선택하겠습니다.
2. last_orders
- order table에 order의 완료 여부를 표시하여 저장. (칼럼의 추가)
굉장히 많은 수의 order가 들어올 텐데.. 만일 order를 영구적으로 보관한다 가정했을 때.. 괜찮을까 + 데이터의 수정이 필요함.
배달의 x족 같은 서비스는 어떻게 order를 관리할까.. 1:n관계이면서 n이 클 확률이 높은 데이터들
(상상해 보기)
a) 어느 정도 시간이 자난 데이터는 백업 후 필요시 서칭 하여 사용
DB(의 분리는 비용과 시간이 클 것 같다.
board 단위에서 쪼개 줄 수 도..?
b) 그냥 다 때려 저장
대용량 DB에 관리에 대해서는 쪼금 궁금해짐.
- order table을 2개의 단계로 쪼갬
a) start_order
b) end_order
DB에서 단계를 쪼개는 것이 좀 멍청한 짓을 하는 것 같다는 생각이 듦.
데이터의 이동.. 을 위해 데이터를 복사 > 삽입 > 삭제를 한다..? 내가 봐도 구려 보인다.
- 프로그래밍적으로 각 member에 대해 last_order라는 테이블을 생성
테이블 검색 어떻게 할래
일단 첫 번째 전략을 선택.
3, area
서비스 설정을 '초기 설정 위치에서 주문'을 가정하였음으로 굳이 area라는 테이블을 나눌 필요는 없어 보임.
4. order와 order_detail... 의 악몽
-나머지 내용 추후 작성-