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

안녕하세요. 3831568님,

쉽지 않은 생각과 사고로 질문해주신 부분 대단하신 것 같습니다.

너무 좋은 질문 해주셔서 감사합니다.

제가 방금 캐나다 벤쿠버에서 오는 바람에 늦게 답을 하게 되었습니다.

먼저 분리하는 게 좋다고만 말씀드린 부분 설명부족에 대해 동의하면서 개선할 부분으로

메모를 해두겠습니다. 피드백 감사합니다.

질문해주신 부분에 대해 의견을 드려보자면, Inventory 테이블로 분리하는 것입니다. DVD 가 한 타이틀의 재고가 10만건이든, 10건이든, Items 테이블은 그 타이틀 하나당 딱 한 행입니다.

재고가 초당 수백번 차감되거나 복구된다면 그 한 행에 WRITE lock 이 계속 걸리고 동시에 관리자가

이 영화 설명 좀 수정하기를 원한다면, 그 행을 기다려야 합니다. 그래서 정적 메타데이터 테이블 Movies, Books, Games 등과 같이 구성되고 Inventory 테이블을 movie_id (FK)

• store_id / location_id (옵션)

• status (‘available’, ‘rented’, ‘lost’ 등)

• available_copies (또는 개별 copy를 한 행씩 관리)

이렇게 하면

• 재고 차감 → Inventory 행만 UPDATE (핫스팟은 여전히 있지만 메타데이터 행은 안 건드림)

• 관리자가 영화 설명 수정 → Movies 행만 UPDATE (재고 트래픽과 완전 분리)

따라서, 분리하는 것을 권장드립니다.

두번째는유형별 재고 관리 정책인데 초기에는 모든 아이템이 그냥 수량만 있다면 OK 될 수 있습니다.

예를 들어, Inventory { item_id, available_count } 이렇게 구성되는 것입니다.

하지만 나중에 요구사항이 생기게 되면 확장이 필요합니다.

유형별로 요구사항은 아래와 같을 것 입니다.

• DVD/블루레이 → 만료일 없음

• 식품 → 유통기한 필요

• 콘서트 티켓 → 좌석 번호, 구역 필요

• 전자책 → 만료일 + 동시 대여 수 제한 필요

• NFT 렌탈 → 소유권 이전 로직 필요

다양한 제한과 확장이 필요할 것입니다.

그래서 아래와 같이 1번 초기부터 3번으로 점점 업그레이드 하는 것을 권장드릴 수 있을 것 같습니다.

1. JSONB / JSON 컬럼으로 유연 속성 보관 (PostgreSQL, DynamoDB 등) – 초중반에 제일 많이 씀

2. 수직 분할 (Vertical Partitioning)

   • 공통: InventoryCommon

   • DVD용: InventoryDVD (expires_at 등)

   • Food용: InventoryFood (expiry_date, batch_no) → JOIN은 귀찮지만 타입 안정성 최고

3. 수평 분할 + Polymorphic Association (제가 제일 추천하는 최종 진화형) Inventory { id, item_id, item_type, available_count, reserved_count, … }

   • 별도 확장 테이블들 → item_type이 ‘dvd’면 InventoryDVD 테이블 조인 → item_type이 ‘ticket’면 InventoryTicket 테이블 조인 (Uber는 결제 수단, Netflix는 콘텐츠별 권한 이렇게 사용될 수 있습니다.)

초기엔 JSONB로 한 다음, 특정 아이템 유형이 너무 복잡해지면 그때 3번으로 분리합니다.

그리고 말씀하신 트래픽이 정말 많아지면 available_count 차감은 결국 Redis / DynamoDB 같은 분산 카운터로 옮기고, DB는 이벤트 소싱이나 사가 패턴으로 최종 일관성만 맞춥니다. (넷플릭스 DVD 재고, 아마존 재고 모두 이렇게 구성될 수 있습니다.)

감사합니다.

좋은 하루 되세요!

안녕하세요, 인프런 AI 인턴입니다. 3831568님께서 질문해주신 영화 DVD 대여 시스템의 데이터베이스 스키마 설계에 관련하여 답변드리겠습니다.

1. 재고 칼럼의 위치

• Inventory Table의 필요성: Inventory Table을 두는 이유는 각 개별 아이템의 상태와 위치, 재고 등을 관리하기 위함입니다. Items Table은 일반적으로 상품의 ‘종류’에 대한 정보를 관리하는 반면, Inventory Table은 ‘실제 물리적 객체’를 관리하기 때문에, 수량을 조정하거나 상태 변경이 잦은 경우에는 Inventory Table을 별도로 두는 것이 효과적입니다.
  
• 트래픽 증가 시 대응: 트래픽 증가로 인해 성능 문제가 발생한다면, 재고 정보의 읽기와 쓰기를 분리하여 성능 배가를 꾀할 수 있습니다. Inventory Table에서 재고 정보를 처리하면, 작성/수정 등을 한 곳에서 관리할 수 있으므로 데이터 일관성을 유지하기 쉽고, 성능 향상에도 유리합니다.
  

2. 유형별 재고 관리 정책 및 확장성 있는 구조

• 유형별 재고 관리 정책: 유형별로 관리할 수 있다면 특정 재고 상태(예: 대여 가능, 수리 중 등) 관리를 Inventory Table에서 구현할 수 있습니다. 이를 통해 각 상태별 조회 및 업데이트가 더욱 용이해지고, 효율적으로 처리할 수 있게 됩니다.
  
• 확장성 있는 구조: 확장성을 고려할 때, Inventory Table을 명확하게 분리함으로써 새로운 유형의 재고나 관리 정책을 추가할 경우에도 쉽게 확장할 수 있는 구조를 갖출 수 있습니다. 데이터베이스의 파티셔닝, 인덱싱 최적화, 캐싱 메커니즘 등을 활용하여 성능 개선도 모색해야 합니다.
  

추가로 참고하실 만한 리소스로, 유사한 주제에 대한 정보가 포함된 게시글을 추천드립니다:
- “데이터베이스 설계에서 테이블 간의 관계 설정 방법”

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