Inflearn コミュニティ Q&A
投稿した質問数
프로덕트와 프로덕트카테고리 사이의 삭제 정책
作成
·
22
1
안녕하세요, 선생님!
좋은 강의 제공해주셔서 감사합니다. 덕분에 단순히 구현에만 집중하기보다, 설계와 개념에 대해 더 고민하면서 코드를 작성하게 되었습니다.
섹션 2의 ‘개념 느끼기’ 부분에서 Product가 Product Category보다 더 상위의 개념이라고 말씀해주셨던 것으로 기억합니다. 저도 그렇게 이해했습니다.
그런데 코드 구현 파트에서 Product와 Product Category 사이의 삭제 정책을 두 가지 예시로 설명해주셨는데, 그 부분에서 한 가지 궁금증이 생겼습니다.
제 생각에는 개념적으로 Product가 더 상위 개념이라면, Product가 삭제될 때 Product Category도 함께 삭제되는 정책이 조금 더 자연스러운 흐름처럼 느껴졌습니다.
이 부분에 대해 제가 개념을 잘못 이해한 것인지, 아니면 실무적인 관점에서 추가로 고려해야 할 부분이 있는지 궁금합니다.
혹시 제가 놓치고 있는 관점이 있다면 조언 부탁드립니다!
回答 2
0
안녕하세요 질문 감사드립니다!
실무 상황마다 다를 수 있지만 일반적으로 삭제 시에 완전 삭제(hard-delete)가 아닌 삭제에 대한 플래그 처리(soft-delete)를 하기 때문에
이 부분은 선택 사항 정도로 볼 수 있을 것 같습니다
다만 데이터의 정합성을 좀 더 중요시 하겠다면, ProductCategory의 상태도 삭제로 동기화 시켜놓을 수 있을 것 같습니다
다만 ProductCategory를 완전 메타 데이터라고 정의한다면 상태 자체도 불 필요 할 수 있을 것 같네요
(메타 데이터이기 때문에 Prodcut가 삭제 상태로 변경 된 상태면 ProductCategory또한 부모의 상태를 따르는 형태, 다만 운영팀에서 삭제 시에 Hard-Delete로 데이터를 정리해야함)
다른 상황과 배경으로는 Product, ProductCategory 모두 각각 상태가 있다고 가정했을때
Product 삭제 시 ProductCategory도 모두 삭제 상태로 변경해뒀을 때
삭제 복원 or 상태 재변경 기능이 있을때 모두 삭제 된 상태인 ProductCategory 중 어떤 것이 실제 삭제 된 것이고 운영팀이 임의로 삭제한 것인지 구분이 안 될 수 있습니다
만약 Product의 상태만 바꿔두었다면 ProductCategory는 복원할 필요가 없고 최종 상태를 그대로 유지하고 있는 것이죠
ProductCategory는 독립적으로 사용 될 가능성이 없기 때문에 반드시 동기적으로 삭제할 필요는 없다는 생각도 들긴합니다
이렇듯 실무에서는 요구사항과 전체 상황을 고려해서 삭제에 대한 전략을 판단이 필요합니다 😃
모쪼록 답이 되었길 바랍니다! 감사합니다!
0
안녕하세요, 인프런 AI 인턴입니다. 신준호님!
제품과 제품 카테고리 사이의 삭제 정책에 관한 깊이 있는 질문을 주셨네요. 이 부분은 설계의 핵심 사항 중 하나로, 시스템의 데이터 일관성 및 비즈니스 로직에 큰 영향을 미칩니다.
제품과 제품 카테고리의 관계 및 삭제 정책에 관한 논의는 다음과 같은 이유에서 중요합니다:
개념적 상위 구조:
- 말씀하셨듯이,
Product가ProductCategory보다 상위 개념으로 정의된다면, 삭제 시에Product삭제는 그에 연결된ProductCategory를 포함하여 삭제하는 것이 자연스러울 수 있습니다. 이는 데이터 일관성과 유지보수 측면에서 고려할 수 있습니다. 다만, 이 경우 실제 비즈니스 로직에서 요구하는 기능과 일치해야 하며, 이로 인해 어느 정도의 데이터 손실이 허용 가능한지를 다시 한번 고려해야 합니다.
- 말씀하셨듯이,
실무적 관점에서의 고려 사항:
- 모든 경우에 동일한 삭제 정책을 적용할 수는 없습니다.
- 예를 들어,
Product가 삭제될 경우 이를 사용하는 다른 도메인이나 기능(예: 기존 주문에서 참조하는 경우)에 영향을 미칠 수 있습니다. 이 경우 기존 데이터를 보호할 전략이 추가적으로 필요할 것입니다.
- 모든 경우에 동일한 삭제 정책을 적용할 수는 없습니다.
유연한 설계:
- 시스템 유지 보수 및 확장을 고려하여 유연한 설계를 도입할 수 있습니다. 예를 들어, 상황에 따라
ProductCategory가 독립적으로 존재할 수 있는 상황이라면,Product와ProductCategory간의 의존성을 줄여 개별적으로 관리할 수 있는 설계를 고려할 수 있습니다.
- 시스템 유지 보수 및 확장을 고려하여 유연한 설계를 도입할 수 있습니다. 예를 들어, 상황에 따라
관련하여 기존의 질문 답변들을 참조하면 도움이 될 수 있습니다:
- 섹션2에서 Product와 Category 간 개념 정리에 대해 질문이 있습니다!: 이 답변에서는 개념의 중요도와 물리적 구현의 차이에 대한 설명이 가능합니다.
- 프로덕트와 카테고리에 대한 질문: 개념도와 실제 구현의 차이를 통해 어떻게 설계할 수 있는지를 설명하는 내용이 있습니다.
고민하신 점들이 잘 해결되길 바라며, 보다 깊이 있는 이해에 도움이 되었으면 합니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.