DeveloperRio DeveloperRio

임베디드 타입을 보면서 mapped superclass 가 생각났다. 비슷한 관점이면서 다른 관점이다. 임베디드는 정말 단위로서 제공을 하는 느낌, mapped 는 상속의 개념. 경우에 따라 잘 활용하면 될 것 같다. 쿼리나 기능적으로 큰 의미는 없어보여 별 쓸말이 없다. https://velog.io/@codemcd/Entity%EC%97%90%EC%84%9C-%EB%A7%A4%ED%95%91-%EC%A0%95%EB%B3%B4-%EB%B6%84%EB%A6%AC%ED%95%98%EA%B8%B0 Entity에서 매핑 정보 분리하기 엔티티를 구현하다보면 여러 엔티티의 공통된 필드를 분리하고 싶은 경우가 있다. 이 때 사용할 수 있는 어노테이션을 정리해보려고 한다. 엔티티를 분리할 때도 상속과 조합을 사용할 ..

JPA 에서는 프록시 객체를 사용하는 경우가 있다. entityManager 의 getReference 를 이용하며, 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체를 조회한 결과를 반환한다. 사용하는 입장에서는 굳이 진짜 객체인지, 프록시 객체인지 확인해가면서 쓸 필요는 없다. 이러한 특징을 이용하면, 지연로딩과 즉시로딩을 이용할 수 있다. 실무에서는 가급적 지연로딩을 사용한다. 즉시로딩은 어마어마한 쿼리가 실행될 수 있으니 지양한다. 상속과 별개로 영속성 명령어를 한꺼번에 실행되도록 전이시키는 설정을 CASCADE 라 한다. 편한 기능인 만큼, 성질을 잘 알고 써야 한다. 또한 고아 객체라는 것이 있다. 부모 엔티티와 연관관계가 끊어지면 자동으로 삭제해주는 기능이다. 삭제 그 이상 그 이하도 아..

상속관계가 있는 데이터를 어떤 식으로 디비에 저장하는 지에 대해서 정리한다. 아이템이라는 부모테이블 아래, 영화, 책 등등 데이터가 있는 구조가 있을 때, 자바 클래스는 차이가 없다. 아예 없진 않지만... Enum 값만 변경해주면 된다. 세가지 방법은, 조인전략, 단일테이블, 테이블마다전략. 간단히 이야기하면 분리하되 FK 를 둔다. 다 합쳐 놓는다. 아예 연관관계 없이 분리한다. 세가지 방법으로 테이블을 구성할 수 있다. 각각의 장단점이 있다. 일반적인 경우는 선호하는 것이 있겠지만, 각각 상황에 맞게 사용하면 될 것 같다. 개인적으로 선호하는 건, 없다... 다 뭔가 장단점이 있어서 상황에 맞게 사용하는 게 좋을 것 같다.

다대다는 처음부터 '사용할 일이 없다' 라고 말하면서 시작한다. 정확히는 '사용하면 안된다' '사용하면 굉장히 불편해진다' 라고 표현하는게 맞는 것 같다. JPA 에서는 데이터를 객체지향적으로 다루는데 목적을 두고 있으므로 다대다에 기능을 제공하고 있다. 그 목적에는 충실하지만, DB 구조상으로 다대다는 굉장한 불편함을 가지고 있으므로 피해야 한다고 말하고 있다. 어떤 불편함이 있어서 --> 이런식으로 하면 편합니다 --> 하지만 처음의 불편함 때문에 이건 피해주세요 개발 공부를 하다보면 이런 경우가 가끔 있다. 와 이거 편하다. 이렇게 하면 좋아 라고 하는데 결국 기존 한계 때문에 다른 한계를 만들 때가 있다. 이런 경우 어떤 것이 더 편한가 불편한가를 따져야 하는지, 그래서 베이직이 더 중요하다라고 ..

처음부터 이러한 매핑은 사용하면 안된다로 시작한다. 어색함의 연속이다. 매핑을 하는 과정에서부터, 일대다를 양방향매핑하는 과정도 어색하다. 심지어 양방향 매핑에서는 읽기전용 다에서 일로 가는 매핑은 아예 존재하지 않는 기능을 insert, update 를 불가하게 함으로 억지로 만들어 내었다. 궁금한 점은 한 가지이다. 이럴거면 왜 만들어놨을까? 테이블의 구조, 매핑의 편리함, 그 어떤 것을 따져보아도 일대다 매핑은 부자연스럽다. 그렇다면 왜 만든 것일까? 관련 문서를 찾아봐야 할 것 같다. 내 머리로는 이해가 되진 않는다. 그리고, 왜 만든 지 이해가 안되 추가적인 내용은 언급하지 않아도 될 것 같다. 방법은 같고, 불편하다.

다대일.... 앞이랑 중복되는 부분이 굉장히 많다. 아마 처음 시작하는 사람들을 위해서 복잡한 부분이라고 생각되어서 여러번 반복해주시는 것 같다. 덕분에 복습을 잘했다. 다대일. 예제로 회원과 팀으로 볼 수 있다. 단방향, 양방향 두가지로 나누어 다루었지만, 사실상 하나의 관계이다. 하나의 관계이고, 이를 객체간의 참조를 양방향에서 할 수 있다. 정도를 다루고 있다. 중요한 건 어느 곳을 연관관계의 주인으로 볼 것인가를 결정한다고 볼 수 있다. 다대다 연관관계는 명시적으로 존재하나, 이러한 연관관계를 설계하면 안된다라는 말씀도 하셨는데 구체적인건 다대다 수업 때 명시하실 듯 하다.

주의할 점은 한가지이다. 주인이 아닌 곳에서의 수정은 반영되지 않는다. 이전에 양방향 연관관계에서 언급한 것처럼, mapped by 는 단방향 연관관계의 참조를 걸어놓은 것뿐이지 연관관계를 추가한 것이 아니다. 주인이 아닌 곳에서 수정을 했다고 해서 연관관계가 추가되어 주인쪽의 데이터까지 함께 수정되는 것을 기대하면 된다. 또한, 이를 예방하기 위해서는 수정 시에 양쪽 다 수정해주는 방법을 권장하고, 이도 문제가 생길 경우를 대비해 수정메소드에 양쪽을 전부 수정하는 방식으로 구현하는 것을 권하고 있다.

앞서 단방향 연관관계를 지정해주면서 외래키를 통해 지정해주는 방법을 보았다. 우리가 두 개의 테이블을 조인할 때 인지하는 방법과 비슷하다. 연관되어 있는 외래키를 가지고 연관을 지어서 조회하는 방식을 사용해왔다. 헌데 다시 생각해보면, 우리는 테이블을 조인해서 조회할때 단방향, 양방향이라는 걸 생각해왔던가? 그런 생각은 해오지 않았다. 그럼 갑자기 왜 단방향, 양방향을 이야기하고 있는 것일까? 위 그림을 보면 우리가 사용하던 테이블의 연관관계는 단방향, 양방향의 개념이 없는 것을 알 수 있다. 그냥 1:1 이냐 1:n n:1 이냐 정도의 개념이다. 하지만 객체 간의 관계에서는 단방향과 양방향이 존재한다. 양방향 매핑을 하면서 주의할 점은 n:1 중, n 인 부분에 연관관계의 주인을 설정해야 한다는 것이다..