[ShellWe 프로젝트] ERD 및 엔티티 연관관계 최적화

이전 개인 프로젝트 포스트(https://mason-lee.tistory.com/159)와 마찬가지로 필요없는 양방향 관계매핑을 없애고 ERD 설계를 다시 해보려 한다.

 

설계를 다시 해보기에 앞서, 지난 포스트에서는 다루지 못했던 단방향 매핑을 적극 활용해야 하는 이유에 대해 알아 보려한다.

 

 

양방향 매핑보다 단방향 매핑을 더 선호하는 이유

1. 단순성과 가독성: 단방향 매핑으로 코드와 매핑 구조를 더 단순하게 유지할 수 있다. 양방향 매핑은 두 개의 엔티티가 서로를 참조해야 하므로 코드가 복잡해지고 가독성이 떨어진다. 
2. 데이터 일관성 유지: 양방향 매핑에서는 한쪽 엔티티를 수정할 때 다른 엔티티도 업데이트 해야한다. 
3. 성능 향상: 양방향 매핑은 객체 그래프를 탐색할 때 불필요한 쿼리가 발생할 수 있다. 예를 들어, A 엔티티와 B 엔티티가 서로 참조할 경우, 한 쪽 엔티티를 로딩할 때 연결된 엔티티까지 로딩되어 서능 저하가 발생할 수 있다.
4. 유연성: 단방향 매핑은 엔티티 간의 관계를 조절하기 쉽다. 양방향 매핑에서는 양쪽 엔티티가 서로를 참조하므로, 한 엔티티를 다른 엔티티와 분리하거나 관계를 변경하기 어려울 수 있다.
5. 오류 가능성 감소: 양방향 매핑에서는 개발자의 실수로 엔티티 간의 참조가 일치하지 않거나 누락될 수 있다. 이로 인해 프로그램이 예상치 못한 동작을 할 수 있다.

 

결국, 단방향 매핑은 코드의 단순성, 일관성 유지, 성능 향상, 유연성 및 오류 가능성 감소와 같은 장점들을 제공하여 객체지향 프로그래밍 다운, 더 나은 설계와 유지보수를 도와줄 수 있다.

 

실제로 이전 프로젝트에서 양방향 매핑으로 인한 불필요한 쿼리 발생이 발견되었으며, 해당 프로젝트와 이전 프로젝트의 엔티티 관계를 양방향 매핑에서 단방향 매핑으로 바꿔주어 관계 매핑 최적화를 시도해 보려했지만 서로 다른 엔티티들과 비즈니스로직들까지 엮여있어 코드의 수정이 쉽지 않은 상황이 발생되었다.

 

물론 상황에 따라 양방향 매핑이 필요할 수도 있을 것이다. 하지만 이번 프로젝트에서는 위와 같은 이유들로 엔티티들간의 연관관계를 다시 한번 되짚어볼 필요를 느끼게 되었다.

 

 

 

ERD 수정

 

수정 전 ERD(왼쪽), 수정 후 ERD(오른쪽)

 

 

ElementCollection이나 Embedded type은 필요가 없어보여 기존의 양방향 매핑을 모두 단방향 매핑으로 변경해 준 모습이다. 실제 엔티티는 불필요한 Setter 메서드들까지 삭제가되어 더 깔끔할 것으로 예상된다.

(수정 : Member 테이블의 email과 emailVerificationStatus, MemberRoom 테이블의 myShellId와 traderShellId를 Embeded 타입으로 묶어 더 독립적으로 테이블을 설계하여 확장성을 높이는 것이 더 좋아보임)

 

• ElementCollection과 Embedded 정리 블로그 : https://mason-lee.tistory.com/158

 

이전 개인 프로젝트와 마찬가지로 해당 프로젝트에서도 비즈니스로직까지 모두 바꿔줄 수는 없었는데 앞으로는 설계단계부터 확실히 준비하여 비즈니스로직까지 완벽하게 마무리해야 될 필요성을 느끼게 되었다.