2-1. 요구사항 분석
간단하게 만들어보자~
---------------------------------------------------------------- 2-2. 도메인 모델과 테이블 설계
다 대 다 일경우 가운데 주문상품을 만들어서 일대다, 다대일로 쪼갬
다대다관계는 가급적 안쓴다.
또, Member, Order 사이를 볼 때 서로가 서로를 가지고 있음 ( 양방향 연관관계 ) - 이것도 가급적 쓰면안됨.
# 엔티티 설계에 있어서 중요한 점
- 개발자가 흔히 하는 실수는 멤버가 주문을 하니까 회원에 orders:List를 둬야겠다!!( 이건 사람 생각 )
사실 시스템은 Member랑 Order랑 동급으로 놓고 고민함.
( 회원을 통해서 주문이 일어난다가 아니라 주문을 생성할 때 회원이 필요하다!!!!!!!!)
쿼리로 들어갈 때도 주문내역이 필요하면 멤버를 찾아서 거기의 orders: List로 주문을 찾아오는게 아니라 그냥 Order에서 필터링 조건에 멤버가 들어가게 될 뿐이다. -> 다쪽인 Order에 FK 놓는다.
# 회원 테이블 분석
DB에 OrderBy...로 시작하는예약어 때문에 Order가 잘 안먹는다. -> Orders
연관관계 주인 쪽에 값을 세팅해야 값이 변경된다.
주인 반대 쪽은 단순히 거울( 조회용) 으로만 쓴다.
객체를 바라보는 것이 외래키??? 객체를 넣을 순 없으므로 외래키사용?
-> 이게 맞는 것같다. 테이블에는 객체를 넣을 수 없으므로 해당 객체로 만들어진 테이블의 PK값을 외래키로 가져온다.
일대일관계는 아무쪽에나 외래키 ( 외래키 쪽이 주인 )
-- 다음 강의는 이 테이블을 코드로 구현