인프런 영문 브랜드 로고
인프런 영문 브랜드 로고

인프런 커뮤니티 질문&답변

큐펀치님의 프로필 이미지

작성한 질문수

실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발

도메인 모델과 테이블 설계

연관관계의 관점

작성

·

50

0

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.

1. 강의 내용과 관련된 질문을 남겨주세요.
2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.
(자주 하는 질문 링크: https://bit.ly/3fX6ygx)
3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.
(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)

질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.
=========================================
[질문 템플릿]
1. 강의 내용과 관련된 질문인가요? (예/아니오)
2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)
3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)

[질문 내용]
여기에 질문 내용을 남겨주세요.

 

회원-주문 관계에서 하나의 회원은 여러 주문을 할수있어서 1:N이라 하셨는데 서버 관점에서 보면 여러 회원이 존재하기 때문에 N:M으로 설계해야 하지 않을까요??

고객 한명당 트랜잭션 관점으로 설계를 해야하는건지 기준이 따로 있는지 궁금합니다..

답변 1

0

인프런 AI 인턴님의 프로필 이미지

안녕하세요, 인프런 AI 인턴입니다. 큐펀치님.

JPA를 사용하면서 회원과 주문 간의 연관관계에 대해 질문해주셨군요. 관련된 설명과 기존 질문들에서의 답변을 바탕으로 안내드리겠습니다.

JPA에서의 연관관계 설정

JPA에서는 일반적으로 각 엔티티 간의 관계를 설정하게 됩니다. 회원과 주문의 관계는 데이터를 어떻게 관리하고 조회할 것인지에 따라 설계할 수 있습니다.

1:N 관계는 한 명의 회원이 여러 개의 주문을 가질 수 있다는 것을 의미합니다. 이것은 일반적으로 고객이 여러 번 주문을 하는 경우에 해당하며, 대부분의 비즈니스 로직에서는 이 설계가 적절하게 작동합니다.

반면, N:M 관계는 각 회원이 여러 주문을 가질 수 있으면서 동시에 각 주문이 여러 회원에게 참조될 수 있는 상황을 말합니다. 일반적인 전자상거래 플랫폼의 고객-주문 관계에서는 맞지 않는 설계입니다. 그러나, 실제 제품의 복잡성에 따라 여러 관계와 매핑 테이블을 사용할 수도 있습니다.

관련된 질문과 답변

유사한 질문에서 다대일 단방향 관계에 관한 설명에 대한 답변을 참고해보시면 이해에 도움이 될 것입니다. 질문자는 왜 회원이 주문을 직접 참조하지 않고, 주문이 회원을 참조하는 단방향 관계를 설정하는지에 대해 질문했습니다. 김영한 강사님은 인터페이스의 복잡성을 줄이고 필요할 때만 참조를 가져오는 것이 더 바람직하다고 설명합니다.

또한 양방향과 단방향 연관관계에 대한 또 다른 질문에서도 다루어진 바 있습니다. 실무에서는 단방향 매핑이 더 간결하게 사용될 수 있으며, 필요에 따라 order에서 member를 조회할 수 있는 방법을 제시하고 있습니다.

구체적인 기준은 요구 사항에 따라 달라질 수 있으며 데이터베이스의 복잡성을 줄이기 위해 단방향으로 간단히 설계할 수 있는 것이 장점일 수 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

큐펀치님의 프로필 이미지
큐펀치
질문자

주문은 공유하지 않기 때문에 1:N이 맞는것으로 이해하였습니다.

그렇다면 수강신청 시스템 같은 경우는 학생-수강 과목에서는 N:M이 맞을까요??

수강 잔여 인원 로직을 구현하기 위해 수강과목에서 학생을 참조하도록 방향을 설정하는게 맞는지 궁금합니다..

y2gcoder님의 프로필 이미지

안녕하세요. 큐펀치님, 공식 서포터즈 y2gcoder입니다.

저라면
강의 : 수강 : 학생 이라는 세 가지 테이블을 두고

강의 : 수강 = 1:N

학생 : 수강 = 1:N

관계로 둘 것 같습니다.

말씀하신 것에서 보면

한 강의는 여러 학생이 수강할 수 있고,

한 학생은 여러 강의를 수강할 수 있기 때문에,

이 수강이라는 개념을 다른 테이블로 분리해줄 것 같습니다.

큐펀치님이 생각하신 설계와는 다를 수 있지만, 저는 보통 위와 같이 먼저 제가 구현해야 하는 기능 및 요구사항을 간단하게 적어보면서 테이블 설계도 해주는 편입니다 🙂

감사합니다.