Auditing을 고려한 테이블 설계 과정

목차

1. 개요

2. Audit 정보

3. Audit 칼럼 정하기

4. 프로젝트 ERD에 Audit 적용하기

5. 결론

1. 개요

테이블을 설계하면서 Auditing을 위한 칼럼들을 어떤식으로 각각의 테이블에 넣어야 할지를 고민했었다.

그래서 이번 정리를 통해 Auditing 칼럼들을 어떻게 테이블에 녹여 낼지 기준을 잡아보려한다.

2. Audit 정보

우선 많은 Audit 칼럼이 존재하는데 살펴본 바로는 아래와 같은 많은 칼럼들이 존재한다.

• 생성일 (Created Date) : 레코드가 생성된 일시.

• 생성자 (Created By) : 레코드를 생성한 사용자 또는 시스템.

• 수정일 (Last Modified Date) : 레코드가 마지막으로 수정된 일시.

• 수정자 (Last Modified By) : 레코드를 마지막으로 수정한 사용자 또는 시스템.

• 삭제 여부 (Deleted Flag) : 물리적 또는 논리적 삭제 여부를 표시.

• 삭제일 (Deleted Date) : 레코드가 삭제된 일시.

• 삭제자 (Deleted By) : 레코드를 삭제한 사용자 또는 시스템.

• 버전 (Version) : 레코드의 버전 정보.

이 Audit 중에 필요한 칼럼을 테이블에 추가하려고 한다.

3. Audit 칼럼 정하기

위에 칼럼을 모든 테이블에 정보를 저장하는 것은 성능에 부담을 줄 수 있을 것이라 생각했고, 데이터 변경 이력을 추적하고 감사 및 검증 목적으로 활용하기 위한 칼럼으로 아래 다섯가지를 선택하였다.

1. created_at (생성일자)
   • 레코드가 생성된 일자와 시간을 추적하여 언제 생성되었는지 파악.

2. created_by (생성자/작성자)
   • 레코드를 생성한 사용자의 식별 정보를 저장하여 레코드 생성자를 파악.

3. updated_at (최종 수정일자)
   • 레코드가 최종으로 수정된 일자와 시간을 추적하여 언제 마지막으로 수정되었는지 파악.

4. updated_by (최종 수정자)
   • 레코드를 최종으로 수정한 사용자의 식별 정보를 저장하여 레코드 수정자를 파악.

5. is_deleted (삭제 여부)
   • 물리적 또는 논리적 삭제 여부를 표시.

4. 프로젝트 ERD에 Audit 적용하기

테이블은 총 8개로 공통적으로 (created_at, created_by, updated_at, updated_by, is_deleted) 이 5가지 칼럼을 가져가려고 한다.

하지만 몇개의 테이블이 해당 칼럼들이 존재하지 않는 테이블이 있을것이다.

1. order 테이블 / is_deleted 존재X
   • order 테이블은 논리적 삭제가 아닌 물리적 삭제를 이용하려고 했고 별도의 order_history 테이블이 존재한다.
   • 주문의 변경되는 상태를 기록하여 추후 문제가 발생하였을시 기록 확인용이 된다.
   • 사용자들이 어떤 상품에 대한 취향이나 선호도를 알 수 있는 통계로도 활용할 수 있다.
   • 유지보수 차원에서 주문의 상태를 조회할 필요가 있다.

2. bid, payment, order_hisotry 테이블 / updated_at, updated_by, is_deleted 존재 X
   • 해당 테이블은 수정이 불가한 테이블이라 생각하여 위에 세 칼럼들 제외했다.
   • 예를 들어 결제가 완료되어서 payment 데이터가 생성되었는데, 결제 취소로 상태값이 변경되는 일이 생기는 것이 이상하다고 생각하였다. 그래서 변경이 이루어지지 않는 테이블에서 생성일자와 생성자 칼럼을 배치하였다.

5. 결론

위에 내용을 정리하면서 프로젝트 ERD를 완성하였다. 하지만 각 프로젝트와 업무, 비지니스 로직, 환경에 따라 다르기 때문에, 실제 사용 시에는 업무 요구사항과 프로젝트의 특성을 고려하여 필요한 데이터를 추가하도록 하자.