3. Model

Pension, Room, Reservation 3개의 메인 테이블

 

1. 최종 가격

• Reservation에서 방 종류, 옵션, 예약 시기, 할인 여부 등에 의해 최종 가격이 정해진다
• 새로운 예약이 만들어질때 입력을 기반으로 최종 가격을 계산하는 로직이 필요

 

2. 삭제 방식

• Pension이나 Room이 삭제되더라도 그와 관계된 Reservation는 남아있어야 하기 때문에 Soft Delete 방식 더 좋다고 판단했음
• 커스텀 Model를 만들어서 상속시키는 방식으로 Soft Delete 구현
  • deleted_at 필드의 값이 null이면 삭제 안된 상태, 특정 날짜이면 삭제 상태
  • 관계가 맺어진 다른 레코드가 삭제될 때 처리(on_delete)는 CASCADE로 결정했지만 구현방식에 대한 고민이 필요함

 

2-1. Hard / Soft Delete

데이터 삭제를 수행하는 방식에 따른 구분

	Hard Delete	Soft Delete
방식	실제로 삭제(물리적 삭제)	삭제 상태로 변경(논리적 삭제)
복원	X	O
구현 난이도	쉬움	번거로움
디스크 사용량	줄어듬	그대로 유지

 

 

2-2. On Delete 방식

ORM에서 참조무결성을 유지하기 위해서 외래키를 통해 참조된 데이터가 삭제될 때 해당 데이터를 처리하는 방식

 

참조무결성이란 기본키와 참조키 간의 관계가 항상 유지되도록 보장하는 것

• 외래키가 가리키는 데이터가 참조하는 테이블에 실제로 있어야 하는 것 

 

(Django 기준)

CASCADE - 둘 다 삭제

PROTECT -  참조된 데이터가 삭제되지 않도록 에러 발생

SET_NULL - 참조된 데이터는 삭제하고 해당 데이터의 외래키 값을 null로 변경

SET_DEFAULT - 참조된 데이터는 삭제하고 해당 데이터의 외래키 값을 미리 정해둔 Default 값으로 변경

SET - 참조된 데이터는 삭제하고 해당 데이터의 외래키 값을 설정된 함수에 따라 변경

DO_NOTHING - 아무런 행동도 하지 않는다 - 참조무결성을 해칠 수 있기 때문에 사용하지 않는다