6. 도메인 모델과 테이블 설계

내가 한

이것과 카테고리 빼면 거의 비슷하다. 아 근데 저거 다대다 관계인데..

또 현실로 보면 한 상품이 여러 카테고리에 포함되어 있을 수 있고, 한 카테고리가 여러 상품을 품을 수 있어서..

 

멤버

아 그렇지 멤버 주소도 있어야 하지..

근데 주소 여러 개 일수도 있으니까 저것도 테이블을 고려 해 봐야 할 듯.

 

주문

Member_id 있어야 하고, 

주문상품도 있어야 하는데, 일대다 관계니 외래키는 다 쪽에 맡기니 여긴 없고,

주문 상태.

주문날짜

 

배송정보

그렇지. 주문과 1:1

주소정보도 있어야 하지. member의 주소와 다를 수 있으니

 

주문아이템

있어야지. 수량, 가격이 다를 수 있지. 할인같은 거

어떤 상품인지도 알아야 겠지.

 

상품

상품이름

가격

양

카테고리

 

카테고리

난 이 쪽이 사실 잘 모르겠음.

 

그거 외에는 괜찮은 듯.

 

역시나 다대다 실무에서는 쓰면 안된다고 한다..

 

그리고 되도록 단방향 연관관계를 쓰라고 한다.

예제기 때문에 양방향을 쓴 곳도 있다고 한다.

 

테이블 먼저 보여주시지.. ㅎㅎ

뭐 예상대로, 비슷하다.

 

근데 요새 보통 보면 아예 카테고리 나눠지는데. 쿠팡도 보면. 하나로만. 넓은 범위의 카테고리 그런 테이블이 따로 있을 뿐이지..

 

그리고 상속관계는 싱글테이블로 표현함.

 

카테고리는 다대다는 안되니 중간에 테이블을 하나 둬

저걸로 다 받게 함.

 

FK만 있는 것으로.

저거라면 납득이 어느정도 감.

 

item_id로 조회해도 모든 카테고리 가져올 수 있고,

카테고리로 검색해도 모든 아이템 가져올 수 있음.

pk도 아니니..

 

 

다음은 연관관계에 대해.

뭐 테이블 연관관계는 그냥 다 쪽이 외래키를 가지고 있고, 다대다도 저런 식으로 풀어내니 넘어가고,

 

객체상의 연관관계.

 

이거는 진짜 그냥 간단히 말하겠다.

 

왜냐하면 예제라고 많은 형태의 연관관계를 집어 넣었기 때문에 오히려 학습에 독이 될 수 있다고 판단했다.

외래키를 있는 쪽이, 즉 다 쪽이 연관관계의 주인이 되면 된다.

 

엔티티 상에서 연관관계의 주인이 된다는 것은, 하인 쪽은 주인에서부터 값을 읽어오기만 할 뿐, 하인의 값을 바꿔도 DB에 반영이 되지 않는다. 근데 주인쪽은 반영이 된다.

 

보통 다대일 단방향이 좋으며, 다 쪽이 연관관계의 주인.

 

물론 꼭 그런 것은 아니지만, 일대일도 있고, 일대다도 있긴 하지만 알아서 잘 쓰면 된다.

그래도 어떤 상태가 되는 지 잘 생각하면서 써라.

근데 다대다는 안된다.