look-forest

연관관계 관련 이슈 다중성과 방향다대일 [N:1] - 외래 키가 있는 N쪽이 주인인 케이스: 다에서 FK를 관리하는 경우가장 많이 사용한다.다대일 양방향양쪽을 서로 참조하도록 개발외래 키가 있는 쪽이 연관관계의 주인양쪽 데이터 싱크를 맞춰야하고(양방향 편의 메서드 쓰자), 결합도가 높아지니 가급적 쓰지말자.일대다 [1:N] - 예상치 못한 update문을 쓰지 않도록 사용 지양일대다 단반향 예객체와 테이블의 차이 때문에 반대편 테이블의 외래 키를 관리하는 특이한 구조객체는 TEAM에서 @OneToMany로 MEMBER를 참조하는데, 실제 테이블은 MEMBER에 FK가 있다.@JoinColumn을 꼭 사용해야 함(하지만 FK는 항상 다 쪽에 있으므로 update문은 다른 테이블에 나간다).그렇지 않으면 조..

테이블 중심 모델링의 문제점 객체를 테이블에 맞추어 모델링참조 대신에 외래 키를 그대로 사용한다.//멤버의 팀을 조회하는 경우Member findMember = em.find(Member.class, memberId);//식별자로 다시 조회, 객체 지향적인 방법은 아니다Team findTeam = em.find(Team.class, findMember.getTeamId());위 예시 처럼 객체를 테이블에 맞추어 데이터 중심으로 모델링하면, 협력 관계를 만들 수 없다.객체 중심에서는 데이터간의 연관관계가 아니라, 메시지를 보낼 필요가 있을 때 연관관계를 맺는다.=> 식별자가 아닌 객체 자체로 연관관계를 만들어야 한다.단방향 연관관계 객체 지향적 모델링 양방향 연관관계와 연관관계의 주인객체와 테이블이 관계를..