물리적으로 외래 키 제약 조건을 설정하지 않을 때
안녕하세요, 이번 강의를 듣고 아주 간단한 질문을 남깁니다.
Soft Delete + 이력 테이블 설계가 필요한 이유가 외래 키 제약 조건으로 인한 삭제 어려움 때문이라 이해했습니다.
일부 실무자들은 이러한 삭제 불편함으로 인해 물리적으로 외래 키 제약조건을 DB에 걸지 않는다는 말을 들은 적이 있는 것 같은데요, 만약 그렇게 제약이 없다면 단순히 Hard Delete + 이력 테이블 구조로 고정해도 괜찮은 걸까요?
답변 1
0
안녕하세요, 인프런 AI 인턴입니다. ZZAMBA님.
외래 키 제약조건을 설정하지 않는 경우와 관련하여 고민하시는 부분에 대해 답변 드립니다. 외래 키 제약조건을 물리적으로 설정하지 않는 이유는 성능 최적화와 설계 유연성을 확보하기 위한 경우가 많습니다. 하지만 이는 데이터 무결성 문제가 발생할 수 있는 점에서 주의가 필요하다고 할 수 있습니다.
외래 키 제약조건 없이 관리하는 전략
Soft Delete 사용: Soft Delete는 삭제된 데이터를 실제로 지우지 않고 플래그를 바꾸어 상태를 관리하는 방식입니다. 외래 키 제약조건이 없는 경우, Soft Delete는 여전히 데이터 관계를 파악할 수 있는 장점이 있습니다.
이력 테이블 사용: 변경 이력 관리를 위해 별도의 이력 테이블을 운영하는 방식은 데이터의 변경 사항을 추적하여 무결성을 간접적으로 보장할 수 있게 해줍니다.
Hard Delete + 이력 테이블 방식: 물리적으로 외래 키를 두지 않고 Hard Delete를 적용해도 무방합니다. 다만, 이 경우 삭제된 데이터의 관계 손실에 주의해야 하며, 이력 테이블을 통해 복구 또는 검증이 가능한 설계를 유지하는 것이 중요합니다.
관련된 질문으로 다음의 답변을 참고하시기를 추천드립니다:
이러한 설계 방법은 데이터베이스의 성능과 유지보수, 그리고 비즈니스 로직의 복잡성에 따라 다양하게 선택될 수 있으며, 실무에서는 주로 성능과 데이터 무결성 간의 균형을 맞추는 것이 핵심 포인트가 됩니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
다음 강의는 언제쯤 나올까요?
0
30
2
실제 FK제약조건을 설정하지 않는이유
0
55
2
히스토리 관련 질문
0
59
2
통계 데이터 수정 질문
1
65
2
공통 코드에서 Redis Pub/Sub은 최근 실무에서 쓰이진 않나요?
0
135
2
DELETE -> SELECT 질문 드립니다.
0
51
1
상속 관계 모델링의 적용 기준 질문
0
75
1
TTL 캐싱에 대한 질문
0
83
1
공통 코드 사용시 컬럼 타입 설정
0
85
1
history_creted_at과 valid_from
1
68
2
함수 기반 인덱스 (Function-Based Index)
0
72
1
추후 강의 질문있습니다
0
128
2
실무 통계 질문(고민) 드립니다..!
0
92
2
Json 컬럼의 객체 맵핑
0
66
1
[Deprecated] 오타 제보
0
87
1
오타 제보
0
76
2
category_path 테이블에서 idx_descendant 인덱스를 생성하는 이유가 궁금합니다
0
97
2
`전체 행 스냅샷 이력 테이블`의 대상 테이블 칼럼 변경
1
88
1
common_code_detail의 code 변경 가능성
1
113
1
[해결책 - 코드값 분리] 중 orders(order_status) - common_code(code) 타입 불일치 제보
0
91
1
이미 문자열 타입인 컬럼을 캐스팅하는 이유
0
107
2
계층 구조 모델링 기타 방법들
0
108
1
섹션 9의 퀴즈가 영어로 출력되요.
0
107
2
섹션 6 SOFT DELETE) UNIQUE 제약 조건 + 가상 컬럼
0
82
1