상태 기반 데이터관리에서 특정 시점에 대한 정보는 어떻게 관리할 수 있나요?
2
投稿した質問数 6
안녕하세요 영한님 마스터패스 구매하고 모든 강의를 재밌게 수강하고 있는 백엔드 개발자 취업준비생입니다. 강의를 듣다가 궁금한 점이 생겨 질문남깁니다! 답변해주시면 너무 감사하겠습니다.
is_deleted 와 같은 컬럼을 사용하는 soft delete 방식은 실제 삭제 시점을 알 수 없기 때문에 주로 사용하진 않고, deleted_at을 컬럼으로 두고 삭제 여부/시점을 모두 판별할 수 있게 한다고 하셨는데,
그렇다면 뒤에 설명해주신 상태 기반 관리를 통해서 ProductStatus나 OrderStatus를 관리할 경우, deleted_at이나 다른 시점을 컬럼으로 두면 나쁜 설계라고 하셨습니다. 그렇다면 결국 ProductStatus와 같은 상태를 가진 것들은 삭제 시점이나 특정 시점을 알 수 없는건 마찬가지 아닌가요?
만약 삭제 시점이나 회원의 탈퇴 시점같은 것들을 관리해야 한다면 어떻게 해야할까요?
이러한 해결 방법으로써 이력 테이블 등의 방법이 있을 것 같은데 취준생의 개인 프로젝트로 사용하기에 규모가 너무 커지지 않을까 걱정됩니다.
실제 사례를 예시로 들어보자면
UserStatus 상태값입니다. 이를 테이블의 한 컬럼으로 두고 내부에는 ACTIVE(정상), SUSPENDED(임시정지), BANNED(영구정지), WITHDRAWN(탈퇴) 등의 여러 상태를 가집니다. 이때 만약 withdrawn_at 컬럼이 존재하지 않고 상태값만으로 관리하면 탈퇴 시점이 언제인지 등을 확인할 수 없게 됩니다.
이 경우에는 withdrawn_at 컬럼을 상태값과 함께 두는 것보다 이력 테이블을 사용하는게 더 나은 설계이자, 개인 소규모 프로젝트에서도 해당되는 사항인지 궁금합니다.
작은 조언이라도 해주시면 감사하겠습니다!
-- 에이전트
인프런 에이전트에 같은 내용으로 질문을 남겨봤는데 withdrawn_at 컬럼을 상태 컬럼과 함께 사용하는 것이 효율적이고 합리적인 설계라고 합니다. 실제로 이력 테이블은 개인 프로젝트 규모정도에서는 사용하기에 관리 복잡도가 증가할 가능성이 있다고 합니다. 이에 대해 어떻게 생각하시는지도 궁금합니다.
回答 0
공통 코드 , 계층 구조 질문
1
71
1
공통코드 관련한 질문 드립니다.
0
92
1
다음 강의는 언제쯤 나올까요?
1
133
2
실제 FK제약조건을 설정하지 않는이유
0
103
2
히스토리 관련 질문
0
84
2
통계 데이터 수정 질문
1
95
2
공통 코드에서 Redis Pub/Sub은 최근 실무에서 쓰이진 않나요?
0
182
2
DELETE -> SELECT 질문 드립니다.
0
77
1
상속 관계 모델링의 적용 기준 질문
0
97
1
TTL 캐싱에 대한 질문
0
130
1
공통 코드 사용시 컬럼 타입 설정
0
118
1
history_creted_at과 valid_from
1
91
2
함수 기반 인덱스 (Function-Based Index)
0
109
1
추후 강의 질문있습니다
0
154
2
실무 통계 질문(고민) 드립니다..!
0
124
2
Json 컬럼의 객체 맵핑
0
89
1
[Deprecated] 오타 제보
0
120
1
오타 제보
0
93
2
category_path 테이블에서 idx_descendant 인덱스를 생성하는 이유가 궁금합니다
0
127
2
물리적으로 외래 키 제약 조건을 설정하지 않을 때
0
124
1
`전체 행 스냅샷 이력 테이블`의 대상 테이블 칼럼 변경
2
110
1
common_code_detail의 code 변경 가능성
1
137
1
[해결책 - 코드값 분리] 중 orders(order_status) - common_code(code) 타입 불일치 제보
0
105
1
이미 문자열 타입인 컬럼을 캐스팅하는 이유
0
127
2