편집된 필드를 표시하기 위해 감사 추적을 어떻게 사용합니까?

Question

제가 진행 중인 프로젝트에서 기록에 적용된 모든 변경 사항에 대한 감사 추적을 생성해 달라는 요청을 받았습니다.감사 추적을 작성해야 하는 것은 이번이 처음이므로 해당 주제에 대해 많은 연구를 해왔습니다.

애플리케이션은 PHP/MSSQL로 개발되며 트래픽이 적습니다.

제가 읽은 내용을 토대로 감사 테이블을 만들고 트리거를 사용하여 테이블의 변경 사항을 기록하기로 거의 결정했습니다.

신청서에 표시하기 위한 두 가지 요구 사항은 다음과 같습니다.

1. 필드에 대한 모든 변경 사항에 대한 로그를 볼 수 있습니다. (저는 이 작업을 수행하는 방법을 거의 알고 있습니다.)

2. 응용 프로그램에서 기록을 볼 때 변경된 기록의 필드 옆에 표시기를 볼 수 있습니다(마지막 변경 날짜와 같은 기타 정보도 가능).

항목 # 2는 현재 나에게 슬픔을 안겨주는 항목입니다.각 필드에 대해 별도의 쿼리(또는 실행하는 데 오랜 시간이 걸리는 매우 긴 중첩 쿼리)를 수행하지 않고 이를 수행하는 최적의 방법에 대한 제안이 있는 사람이 있습니까?(테이블의 각 필드에 대해 필드가 편집된 경우 부울 표시기 역할을 하는 추가 "ModifiedFlag" 필드를 추가하려고 생각했지만 이는 많은 오버헤드처럼 보입니다.

Answer 1

감사 정보는 가능한 한 실제 도메인 정보와 별도로 취급하겠습니다.

요구 사항 #1:변경 사항을 기록하기 위해 추가 감사 테이블을 만들 것이라고 생각합니다.Eric의 제안은 SQL 데이터베이스의 트리거를 사용하여 감사 정보를 생성하는 좋은 제안입니다.이렇게 하면 애플리케이션이 감사 논리를 인식할 필요가 없습니다.

데이터베이스가 트리거를 지원하지 않는 경우 일종의 지속성 또는 데이터베이스 계층을 사용하고 있을 수 있습니다.또한 이러한 종류의 논리를 배치하기에 좋은 장소가 될 것입니다. 다시 말하지만, 정상 애플리케이션 코드와 감사 코드.

요구 사항 #2:표시기를 표시하는 방법은 다음과 같습니다.나는 실제를 저장하는 테이블에 부울 필드를 생성하지 않을 것입니다.(이로 인해 사용자와 사용자 사이에 모든 종류의 종속성이 존재하게 됩니다. 정상 애플리케이션 코드와 귀하의 감사 추적 암호.)

양식 표시를 담당하는 코드가 필드 수준에서 감사 데이터 표시도 담당하도록 하려고 합니다.이로 인해 쿼리 오버헤드가 발생하지만 이는 추가 정보 계층을 표시하는 데 드는 비용입니다.쉽게 검색할 수 있도록 감사 정보에 ​​메타데이터를 추가하면 데이터베이스 오버헤드를 최소화할 수 있습니다.

내가 유지 관리하는 일부 대형 Enterprise 애플리케이션은 대략 다음과 같은 구조를 사용합니다.

• 테이블의 레코드 변경에 해당하는 변경 헤더 테이블입니다.

필드:

changeId, changeTable, changedPrimaryKey, userName, dateTime

- 변경된 필드에 해당하는 변경 필드 테이블.

필드:

changeId, changeField, oldValue, NewValue

샘플 콘텐츠:

헤더 변경:

'1', 'BooksTable', '1852860138', 'AdamsD', '2009-07-01 15:30'

항목 변경:

'1', 'Title', 'The Hitchhiker's Guide to the Gaxaly', 'The Hitchhiker's Guide to the Galaxy'
'1', 'Author', 'Duglas Adasm', 'Douglas Adams'

이 구조를 사용하면 감사 추적을 쉽게 볼 수 있을 뿐만 아니라 원하는 지표를 표시하기 위해 쉽게 검색할 수 있습니다.하나의 쿼리(헤더 및 항목 테이블의 내부 조인)는 단일 양식에 표시할 모든 정보를 검색하는 데 충분합니다.(또는 표시된 ID 목록이 있는 경우 테이블도 가능)

Answer 2

일반적인 요구 사항으로 변경된 필드는 "냄새"가 약간 이상합니다. 기록이 오래 살면서 시간이 지남에 따라 변경 될 수 있다면 결국 모든 필드는 신고되는 경향이 있습니다. 따라서 어떤 사용자가 필드 당 간단한 지표 세트를 어떻게 이해할 수 있는지 궁금합니다.

이러한 사고 라인으로 인해 저장 한 데이터가 설명 된 모든 변경 사항이 기록 된 진정한 감사 트레일이어야하며 첫 번째 실제 과제는 정보를 사용자에게 제시하는 방법을 결정하는 것입니다.

나는 어떤 종류의 집계에 대한 당신의 아이디어가 TheauditTrail 데이터를 매우 유용 할 것이라고 생각합니다. 문제는 레코드 당 단일 깃발일까요? 사용자의 기본 액세스가 목록을 통과하는 경우 나중에 드릴 다운을 위해 변경된 레코드를 강조하기에 충분할 수 있습니다. 또는 레코드 값의 마지막 변경 날짜는 최근에 변경된 레코드 만 강조 표시됩니다. 모두 사용자의 실제 요구 사항으로 돌아갑니다. 3 년 전의 기록이 지난주에 바뀌었던 것만 큼 간격하다고 상상하기가 어렵다는 것을 알게되었습니다.

그런 다음 우리가 드릴을 단일 레코드로 내려 오면. 다시 필드 당 간단한 플래그는 유용하게 들리지 않습니다 (도메인, 요구 사항). 그렇다면, 요약 아이디어는 괜찮습니다. 내 생각에 필드에 대한 일련의 변화와 레코드에 대한 전반적인 변화의 순서가 훨씬 더 흥미로울 것입니다. 직원은 임금 인상, 직원 이동 부서, 직원이 승진했습니다 = 3 개의 별도 비즈니스 이벤트 또는 1 명입니까?

간단한 깃발 이상이 필요한 경우 레코드에 대한 전체 (또는 최근) 감사 트레일을 반환하고 UI가이를 제시하는 방법을 알아 내야한다고 생각합니다.

그래서 나의 초기 생각 : 요약 레코드의 일종의 롤링 유지 보수는 좋은 생각처럼 들립니다. 필요한 경우 백그라운드 스레드 또는 배치 작업으로 유지 관리합니다. 우리는 매번 완전한 감사 트레일에 가지 않고 사업을 사용하지 않는다고 생각합니다. 그런 다음 상세한 분석을 위해 트레일의 일부 또는 전부를 검색 할 수 있습니다.

Answer 3

개인적으로 저는 추적을 단순하게 만들고 보고를 펑키하게 만들고 싶습니다.

사용자가 레코드를 삽입할 때마다 해당 테이블에 대한 감사 테이블에 삽입됩니다.

'I', 'Date', 'User', 'Data column1','Data Column2', etc.

이는 테이블의 구조가 시간이 지나도 변경되지 않을 것이라고 가정합니다(re.데이터 열의 양)

업데이트하려면 다음을 삽입하세요.

'U', 'Date', 'User', 'Data column1', etc

사용자가 업데이트로 방금 입력한 내용을 삽입합니다.

그런 다음 삽입 및 업데이트 후에는 다음과 같은 결과가 나타납니다.

'I','May 3 2009','BLT','person005','John','Smith','Marketing'
'U','May 4 2009','BLT','person005','John','Smith','Accounting'

그런 다음 고유한 개인 레코드 'person005'에 부서가 업데이트된 삽입 및 업데이트가 있음을 보여주는 간단한 보고서입니다.

시스템 사용량이 낮기 때문에 변경 시 간단한 삽입을 수행하는 것보다 더 복잡한 보고 프로세스를 수행하는 것은 성능에 영향을 미치지 않습니다.이 스타일은 편집 시 추가 로드가 최소화되므로 트래픽이 많은 시스템에서 계속 작동하는 반면, 변경 사항을 다시 보고하는 더 높은 강도의 워크로드는 업데이트만큼 자주 수행되지 않으므로 시스템이 넘어지지 않습니다.