다대다 관계에 대해서 몇가지 질문드립니다.

Question

[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 비지니스 요구 사항에 맞게 엔티티를 설계할 때 비지니스가 복잡하고 현실과 맞게 설계하기 위해서 고민하다 보니 다대다 관계가 많아지는 것 같습니다   배운대로 OrderItem과 같이 모두 중간에 엔티티를 만들어 1대다로 바꾸었습니다만 몇가지 의문이 드는 부분이 있어서 질문드립니다.   다대다 관계를 위해 중간 엔티티와 테이블을 만들다 보니 의미없는 엔티티와 테이블이 많아지는 것 같습니다. 이런 경우 설계가 잘못되었다고 판단할 수 있나요 OrderItem과 같은 중간 엔티티에 대한 리포지토리를 만들면 조회가 편해지고 조인 횟수를 줄일 수 있을 것 같습니다. 그런데 이런 것은 설계적으로 바람직하진 않은가요?   언제나 답변 감사합니다

y2gcoder · Answer

안녕하세요. 김세희님, 공식 서포터즈 y2gcoder입니다. 주로 다대일 관계와 다대다 관계 중 어느 것이 좋냐고 따질 때는 요구사항을 기준으로 생각해보시면 좋을 것 같습니다. 저희가 구현해야 하는 요구사항을 면밀히 분석했을 때, 보통 해당 단계에서는 다대다 관계가 필요치 않으면 다대일로 구현해놓는 것이 맞았던 것 같습니다. 경험상 의외로 다대일로 구현한 것을 다대다로 변경할 일이 많지 않았습니다! 물론 제가 경험이 많지 않아서 그럴 수도 있습니다 그렇게 하셔도 됩니다. 제가 개발하면서 제일 많이 듣는 말 중에 하나가 비용인 것 같습니다. A를 했을 때의 비용과 A를 하지 않았을 때의 비용, 리팩토링 비용, 기능 추가를 위한 비용 등 개발할 때는 참 비용이 중요한 문제라 생각합니다. 김세희님께서도 중간 엔티티에 대한 레포지토리를 생성하고 그것을 기준으로 코드를 짰을 때, 그렇지 않았을 때보다 총 비용이 줄어든다고 생각하시면 그렇게 하시면 됩니다. 물론 그 비용을 따지는 것은 쉽지 않은 문제라고 생각합니다. 그래도 개발하시면서 계속 비용에 대해 생각하시다 보면 점점 비용을 산정하는 자신만의 기준이 생기실 거라 생각합니다 :)   감사합니다.