작성
·
27
·
수정됨
0
안녕하세요 영한님!
강의를 들으면서 쇼핑몰 요구사항을 조금 더 확대해서 직접 모델링해보고 있습니다. (Store, Delivery, ...)
엔티티를 분류하고 개념적 모델링, 논리적 모델링을 진행하면서 몇 가지 궁금한 점이 있어서 질문드립니다.
현재 강의에서는 Order - OrderItem - Product 관계가 존재했고,
만약 Store와 Product 사이에 "무엇"을 등록한다
라는 관계가 존재한다면,
Order - OrderItem - Product - Store 이렇게 관계가 형성될 것 같습니다.
질문 1. Order와 Store 관계
Order와 Store 사이에, "어디에서" 주문한다
라는 관계가 있다고 볼 수 있는지 궁금합니다.
(비즈니스 적으로 의미가 있는지에 따라 관계 여부를 결정하는게 맞을까요?)
질문 2. 만약에 관계가 존재한다고 생각하면 Order와 Store를 직접적으로 관계를 맺어주는게 좋을지, 아니면 그래프 탐색을 통해 관계를 참조하는게 좋을 지 궁금합니다.
사실 Order - OrderItem - Product - Store 순으로 모두 Join 하면, 직접적인 연관관계를 맺지 않아도 원하는 데이터를 조회할 수 있을 것이라고 생각하는데요.
만약에 Order와 Store만으로 구성된 화면이 존재하거나, Store 정보를 바탕으로 Order를 필터링 해야한다면, Order에 Store의 식별자를 가지고 있으면 편하게 조회할 수 있을 것 같더라고요.
다만, 이렇게 되면 화면이나 Api에 의존적이게 모델링되는 것 같은데, 이러한 설계 방식이 괜찮은 방식인지 궁금합니다.
답변 1
0
안녕하세요, 인프런 AI 인턴입니다.
질문해 주신 내용을 보니 데이터베이스 설계에 대한 깊이 있는 고민을 하고 계신 것 같네요. 강의를 기반으로 데이터 모델링을 확장하고 있으신데, 실전에 적용할 수 있는 구체적인 질문을 주셔서 감사드립니다.
Order와 Store 사이의 관계를 설정할 필요가 있는지를 고민하셨는데요, 비즈니스 로직에 따라 지정됩니다. 예를 들어, 각 주문이 특정한 Store에서 발생하는 것으로 간주되어야 한다면 “어디에서 주문한다”라는 명제는 의미가 있습니다. 이는 비즈니스 요구사항에 의해 결정되어야 하며, 이러한 요구사항이 있으면 관계를 설정하는 것이 타당합니다.
Order와 Store를 직접적으로 참조하기 위해 관계를 설정하는 것은 특정한 사용 사례에 따라 결정될 수 있습니다. 예를 들어:
- 특정 Store의 주문을 자주 조회하거나 필터링해야 한다면 Order에 Store의 식별자를 직접 저장하여 효율적으로 조회할 수 있습니다.
- 그러나 데이터 모델이 API나 특정 화면에 종속되는 것은 어느 정도는 피하고 싶은 설계입니다. 따라서 데이터 변경의 유연함과 확장성을 고려해 장점과 단점을 잘 비교해 보셔야 합니다.
이때 중요한 것은 비즈니스 로직을 지원하면서도 데이터의 정합성과 확장성을 최대한 유지할 수 있는 쪽으로 설계하는 것입니다. Order와 Store 간의 직접 관계를 지원함으로써 얻는 이점이 많다면, 이를 활용하되 데이터 모델의 향후 변경 가능성도 염두에 두시면 좋겠습니다.
아래의 게시물을 통해 비슷한 고민을 한 다른 질문과 답변을 참고할 수 있습니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.