qwef

실무에서 이건 쓰면 안된다고 함. RDB는 사실 테이블 2개로 다대다 표현 불가. 야매로 할 수 있긴 한데, 중간에 테이블 하나로 묶어서 객체는 다대다가 되긴 함. 결론은 다대다 쓰지 말기로..

주인 테이블이나 대상 테이블 아무대나 선택해서 외래키 넣어도 됨. 외래키에 DB 유니크 제약조건 추가해야 함. 하긴. 1:1이니 고유해야 함. 예를 들자면 회원의 사물함. 1:1 관계 여기선 MEMBER테이블에 외래키를 넣었는데, 어디에 넣든지 상관 없음. 다대일과 유사하기도 함 @Entity public class Member { @Id @GeneratedValue @Column(name = "MEMBER_ID") private Long id; @Column(name="USERNAME", nullable = false) private String name; @OneToOne @JoinColumn(name = "LOCKER_ID") private Locker locker; } 이렇게 추가. @Entity..

1이 연관관계의 주인일 경우. 테이블이 아니라 객체상의 경우를 말하는 거다. 근데 이 관계는 권장하지 않는다. 일단, 이 모델은 거의 사용하지 않는다고 보면 된다. 물론 객체 입장에서는 team이 member들을 가지고 있는거니 좋아보이긴 하지만.. 또 뭐 Member입장에서 team을 알고 싶지 않다 그럴 수도 있고. DB상에서는 무조건 다 쪽에 외래키가 있다. 즉 다쪽인 MEMBER에 외래키. 그러면 1 쪽(team)을 연관관계 주인으로 보면, 만약 팀 변경 시 Team을 통해서 다른 테이블인 MEMBER 테이블의 외래키를 update 처리 해 줘야 한다. 즉, 다른 테이블 이기 때문에, (그렇다고 Member가 주인이 아니라 Member로 반영도 못하고) 결국 Team으로 저장을 해야 하는데, 근데..

연관관계는 N : 1 1 : N 1 : 1 N : M 이렇게 있는데, 이번에는 N : 1을 알아볼 것이다. 즉, N이 연관관계 주인일 경우 연관관계 매핑 시 고려사항은 다중성 단방향, 양방향 양방향 일 시 연관관계 주인 다중성 @ManyToOne @OneToMany @OneToOne @ManyToMany 이런 다중성 다 JPA가 제공 JPA의 애노테이션은 거의 전부 DB와 매핑하기 위해 있다고 생각하면 됨. DB관점에서 다중성을 보면 됨. 다중성이란 일대다 같이 그런 관계를 말하는 거임. 뭐를 다로 해야 하고 뭐를 일로 해야 할 지. 근데, @ManyToMany 다대다는 안 씀. 쓰면 안됨. @ManyToOne 많이 씀 @OneToMany 필요하다고 느끼면 씀(양방향일때 쓰는 듯) @OneToOne 가끔..

이게 테이블 구조고, 객체도 이거와 별반 차이가 없었다. 우선은 단방향부터 잘 매핑하고, 그 후 필요하면 양방향 하겠다. 먼저, Member @Entity public class Member { @Id @GeneratedValue(strategy = GenerationType.AUTO) @Column(name="MEMBER_ID") private Long id; private String name; private String city; private String street; private String zipcode; } 바뀐 것은 없다. 그 다음 Order. 얘는 이제 외래키에서 참조로 바꿔야 한다. 그리고 다대일매핑이다. @Entity @Table(name="ORDERS") public class O..

JPA입장에서는, 연관관계의 주인에게만 값을 넣어주면 되지만, 사실 객체지향 입장에서는 둘 다 넣어줘야 한다. Team team = new Team(); team.setName("TeamA"); em.persist(team); Member member = new Member(); member.setName("member1"); member.setTeam(team); em.persist(member); tx.commit(); 여기서 보면, DB상으로는 문제가 없다. Team 생성한 다음에, persist 해서 id까지 완벽히 넣고 영속성 컨텍스트에 까지 넣고, Member를 만들어 그 만든 team을 넣어주고, Member도 마찬가지로 영속성 컨텍스트에 넣어준다. DB상으로는 제대로 반영이 되었다. 근데,..

양방향 연관관계 Member의 team과 Team의 members 처럼 양쪽 둘다 가지고 있는. 일단 테이블 연관관계는 바뀐 게 없다. 생각해보면, member에서 팀을 알고 싶으면 team의 team_id를 기준으로 조회해보면 되고, team에서 자기 팀인 member를 알고 싶으면, 내 team_id를 가지고 있는 member들을 조회해 보면 된다. 그냥 join 하면 된다. 사실상 테이블의 연관관계는 방향이라는 개념 자체가 없다. 그냥 외래키 있으면 양쪽 둘 다 알 수 있다. 근데 객체가 문제다. 저렇게 객체지향적으로 바꾸게 되면, 과거처럼 객체도 테이블 설계적으로 세팅했다면 그냥 외래키로 소통하면 되었을 테지만.. 코드 @Entity public class Member { public Member..

저번 예제에서 Entity를 테이블 중심으로 설계를 했더니, 객체 입장에서 실제 참조를 가지지 않게 되었다. 어떻게 객체지향 적으로 설계를 할 수 있을까? 어떻게 실제 Order가 Member 객체를 참조하도록 설계할 수 있을까? 이렇게 관계형 DB와 객체 사이의 패러다임 불일치를 어떻게 해결할 수 있을까? 객체 : 주소, 참조를 통해 연관관계 설정 테이블 : 외래키를 통해 연관관계 설정 결국, 객체의 참조 부분과 테이블의 외래키 부분을 매핑 시켜야 한다. 이런 상태니, 음 근데 객체는 Member를 직접 가지고 있는 형태이고, 그러니까, DB의 저런 관계를 가져와서 객체로 만들어야 하는 것 인데, 일단 솔직히 insert는 쉬워보이고.. 쿼리를 그냥 Order 쿼리 날릴 때 Order Table에 미리..

요구사항 회원은 상품 주문 가능 주문 시 여러 종류 상품 선택 가능. 프론트엔드 체크하고 개수 입력 후 주문버튼 누르면 post 방식으로 전송 백엔드는 이런 느낌이려나..? 1 : N, N : N 이런 관계를 중요시 보는 듯. 한 회원은 여러번 주문 가능 (1 : N) 한 주문에 여러 상품 선택 가능 (1 : N) 한 상품은 여러 번 주문될 수 있음(N : 1) 테이블 설계 Member는 그냥 member고, orders는 주문이 있다는 어떤 식별자 같은 거 겠고, 주문의 상태 등도 나타낼 수 있는. 여러 order_item이 하나의 orders를 가리킬 수 있고, order_item과 item이 1:1 관계가 아닌 게 조금 의아했다. 그냥 order_item에서 count로 숫자로 나타내면 되는 거 아..

우리가 테이블에서 id에 넣는 그 키 그 테이블의 primary key 같은 것 들과 @Entity에서 어떻게 매핑을 할 지 id를 직접 넣어주고 싶다, @Id만. DB가 자동으로 Generate 해주는 것을 쓰고 싶다, @GeneratedValue를 추가해 줌. @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; 전략 = 옵션 이렇게 넣는다. default가 AUTO이다. AUTO는 DB마다 좀 다르다. 아마 하이버네이트가 기본으로 설정한? 그런 건가 보다. 방언마다 다르다. 확인 해 보고 써야 함. 여튼 저게 기본값이고, 실상은 3개이다. IDENTITY SEQUENCE TABLE AUTO는 저 셋중 하나를 쓰는거다. IDENTI..