데이터베이스에는 CRUD에 해당하는 기능들이 모두 존재하나 soft delete를 위하여
DELETE 메소드가 호출되어도 실제로 데이터베이스에서 레코드가 삭제되지는 않는다

이때 삭제된 데이터는 soft delete 되었다는 속성을 가져 서비스에서 사용되지 않게 되거나
history테이블로 옮겨져 log로서의 성격을 갖게 된다

이력 테이블 설계

테이블과 history를 분리

대상 테이블에서 이력을 남길 속성을 갖는 테이블을 새로 생성하고
수정 소요가 발생할 때마다 대상 테이블의 대상 속성을 복사하여
history테이블의 레코드로 저장하고 대상 테이블을 update

테이블과 history를 같이 관리

해당 레코드에 수정 소요가 발생하면 새로운 레코드를 만들고
이전 레코드를 이력으로 취급한다

차이점

history를 분리하는 방법을 취할 경우 수정 이력을 보관해야하는 모든 테이블에서
history 테이블을 따로 만들어줘야 한다. 이를 통해 얻을 수 있는 장점은
현재 사용중인 데이터를 조회하기 위한 특별한 로직이 필요없다

history를 같은 테이블에서 관리하는 방법을 취하면 테이블을 새로 만들지 않아도 되지만 
무엇이 이력이고 무엇이 현재 사용되는 데이터인지 구분해주어야 할 필요성이 생긴다

이력 관리 방법

점이력

이력이 발생한 시간만을 기록하는 방법
이력을 순차적으로 조회하거나 전체 이력을 보여줄 필요가 있을 때 적절

선분이력

이력이 발생한 순간(created_at), 이력이 유효한 시간(modifided_at)을 기록하는 방법
특정 시간대의 이력을 조회하려 할때 적절하다