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

안녕하세요! 질문 감사드립니다!

우선 현재 기준으로는 요구사항 자체가 카테고리에 여러 상품이 들어갈 수있고, 상품도 여러 카테고리에 들어갈 수 있다는 가정이 있었기 때문에 N:N 구조가 필요했다고 봐주시면 될 것 같습니다 😃

말씀해주신 것 처럼 운영 중 요구사항 변경으로 인해 N:N이 나오는 상황이 실무에선 허다하죠ㅎㅎ;;

다만! 저는 처음 부터 N:N 관계로 정의하는 것은 선호하지 않습니다!
(말씀해주신 부분 처럼 어짜피 그렇게 될거라면...도 일리가 있습니다만..! 관련 의견은 아래 섹션에 후술)

왜냐하면 모든 케이스를 N:N으로 정의하면 전체적으로 불필요하게 부피와 허영이 커지는 느낌이라 생각하기 때문입니다, 유연함은 유지가 되는 듯 하지만 실제 요구사항과 개념의 본질과 멀어지는 느낌이랄까요?

그런 부분 때문에 소프트웨어를 잘 만든 다는 관점에서 일반적인 경우는 요구사항을 충분히 체크해보고 상황에 맞추어 1:1, 1:N 으로 시작하는것이 좋다고 생각하긴합니다!
(물론 딱 봐조 이건 백퍼 요구사항 커지겠네...... 싶은 상황이라면 N:N 가야죠!ㅎㅎ)

추가로 또 다른 관점으로는 이런 판단은 개발 관점으로만으로만 결정 할 수 없는 것 같습니다.
결국 기획팀 또는 상위 조직장의 수준(?)이나 행태, 전적(?)을 살펴봐야합니다ㅎㅎㅎ..

진짜로 맨날 요구사항을 자주 저 정도 수준으로 뒤짚어 엎어버린다면 저라도 N:N을 기본 값으로 하는 선택을 할 것 같긴합니다 😅 (물론 요구사항의 개념이 딱 봐도 N:N 될 가능성이 높은지 검토도 필요하죠!)
그렇지만 일반적인 수준이라면 1:1, 1:N 으로 접근하다가 꼭 필요시 N:N 으로 설계할 것 같습니다!

종합적으로는 개념의 본질을 유지하면서 요구사항 제공자와 회사의 느낌까지 복합적으로 생각해서 트레이드 오프를 하는 것이 좋다고 생각합니다!

모쪼록 답이 되었길 바랍니다! 완강 후 수강평도 기대하겠습니다!
추가 질문이 생기면 편하게 물어봐주세요! 감사합니다!

안녕하세요, 인프런 AI 인턴입니다. Son원철님!

Product와 Category의 관계를 N:N으로 설계하신 점에 대해 궁금해하시는군요. 이 과정은 설계에서 매우 중요한 결정 중 하나로, 앞으로의 확장성과 구조의 유연성을 고려한 전략입니다. 제가 유사한 질문에 대한 기존 답변을 찾아보았습니다.

1. “섹션2에서 Product와 Category 간 개념 정리에 대해 질문이 있습니다!”

   • 여기에서 Product와 Category 관련하여 상호 개념의 중요도와 설계 기준이 설명되었습니다. 프로젝트에 따라 N:N 설계는 장기적인 관점에서 관계의 유연성과 확장성을 제공할 수 있습니다.
     

2. “초기 서버 스펙·인프라 가정 및 ProductCategory 설계 기준 관련 질문”

   • 해당 링크에서는 ProductCategory가 가지는 역할과 이를 통해 이루어지는 연관관계 설계의 기준에 대해 다루고 있습니다. 특히 N:N 관계가 아닌 다른 구현 방식과 비교하여 결정하는 기준에 대해 설명되고 있습니다.
     

Product와 Category 간의 관계를 N:N으로 설계하는 이유는, 실제 비즈니스 환경에서 두 개체 간의 관계가 변화할 가능성이 높기 때문입니다. 이 경우, 매핑 테이블을 통해 유연하게 관계를 관리할 수 있으며, 새로운 요구사항이 발생할 때 구조적 변화를 최소화할 수 있는 이점이 있습니다.

Status(상태)와 같은 데이터의 중복은 경우에 따라 종종 발생할 수 있는 트레이드오프이며, 이는 비즈니스 모델의 필요에 따라 적절히 관리되어야 할 부분입니다. 이러한 트레이드오프를 고려하여, 설계 시점에서 유연성과 유지보수의 필요성을 균형있게 판단해야 합니다.

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