ChangeLog / 감사 데이터베이스 테이블을위한 최상의 디자인? [닫은

StackOverflow https://stackoverflow.com/questions/201527

  •  03-07-2019
  •  | 
  •  

문제

다른 변경 로그/감사를 저장하려면 데이터베이스 테이블을 작성해야합니다 (추가, 삭제, 수정 등). 특히 상세한 정보를 저장할 필요가 없으므로 다음의 라인을 따라 무언가를 생각하고있었습니다.

  • ID (이벤트 용)
  • 그것을 트리거 한 사용자
  • 이벤트 이름
  • 이벤트 설명
  • 이벤트 타임 스탬프

내가 여기서 뭔가를 놓치고 있습니까? 분명히 디자인을 계속 개선 할 수는 있지만 복잡하게 만들 계획은 없지만 (이벤트 유형을위한 다른 테이블을 만드는 것은 내 필요에 대한 합병증이기 때문에 의문의 여지가 없습니다).

도움이 되었습니까?

해결책

내가 작업중 인 프로젝트에서 감사 로그는 설명한 것과 같이 매우 최소한의 디자인에서 시작되었습니다.

event ID
event date/time
event type
user ID
description

아이디어는 동일했습니다. 물건을 단순하게 유지하는 것.

그러나이 미니멀리즘 디자인이 충분하지 않다는 것이 분명해졌습니다. 일반적인 감사는 다음과 같은 질문으로 끓고있었습니다. 

Who the heck created/updated/deleted a record 
with ID=X in the table Foo and when?

따라서 이러한 질문에 신속하게 답변하려면 (SQL 사용) 감사 테이블에 두 개의 추가 열이 있습니다.

object type (or table name)
object ID

그때 감사 로그의 디자인이 실제로 안정화되었습니다 (현재 몇 년 동안).

물론 마지막 "개선"은 대리 키가있는 테이블에만 효과가 있습니다. 하지만 그거 알아? 감사 할 가치가있는 모든 테이블은 그런 열쇠가 있습니다!

다른 팁

테이블/칼럼 이름, 컴퓨터/응용 프로그램 등이 더 많은 것들이 더 많은 것들이 더 있습니다.

이제 이것은 당신이 실제로 필요한 세부 감사와 어떤 수준에 있는지에 달려 있습니다.

우리는 자체 트리거 기반 감사 솔루션을 구축하기 시작했으며 모든 것을 감사하고 복구 옵션도 갖고 싶었습니다. 이것은 너무 복잡한 것으로 판명되었으므로 트리거 기반의 타사 도구를 리버스 엔지니어링했습니다. ApexSQL 감사 우리 자신의 커스텀 솔루션을 만들기 위해.

팁 :

  • 전/후 값을 포함합니다

  • 기본 키를 저장하기위한 3-4 열 포함 (복합 키 인 경우)

  • Robert가 이미 제안한대로 메인 데이터베이스 외부에 데이터를 저장

  • 보고서 준비에 적절한 시간을 보내십시오 - 특히 회복에 필요한 사람들

  • 호스트/애플리케이션 이름 저장 계획 - 이는 의심스러운 활동을 추적하는 데 매우 유용 할 수 있습니다.

또한 구식 및 새 값과 그 열을 기록한 열과 감사 세부 사항 테이블에서 감사하는 테이블의 주요 키를 기록합니다. 감사 테이블이 무엇인지 생각하십니까? 누가 변화를 겪었는지, 그리고 언제 나쁜 변화가 일어날 때, 당신은 데이터를 되돌릴 수있는 빠른 방법을 원합니다.

설계하는 동안 데이터를 복구하기 위해 코드를 작성해야합니다. 회복해야 할 때는 일반적으로 서두르며 이미 준비하는 것이 가장 좋습니다.

여기와 비슷한 질문에는 많은 흥미로운 답변이 있습니다. 개인적인 경험에서 추가 할 수있는 유일한 것은 다음과 같습니다.

  1. 감사 테이블을 다른 데이터베이스에 넣으십시오. 이상적으로는 원래 데이터와 분리를 원합니다. 데이터베이스를 복원 해야하는 경우 감사 트레일을 복원하고 싶지 않습니다.

  2. 합리적으로 가능한 한 비정상화. 테이블이 원래 데이터에 최대한 적은 종속성을 갖기를 원합니다. 감사 테이블은 간단하고 빠르게 데이터를 검색해야합니다. 다른 테이블에 대한 멋진 조인이나 조회는 데이터에 도달하지 않습니다.

우리가 테이블에 가지고있는 것 :-

Primary Key
Event type (e.g. "UPDATED", "APPROVED")
Description ("Frisbar was added to blong")
User Id
User Id of second authoriser
Amount
Date/time
Generic Id
Table Name

일반 ID는 업데이트 된 테이블의 행을 가리키고 테이블 이름은 해당 테이블의 이름입니다. 좋은 DB 디자인은 아니지만 매우 유용합니다. 모든 테이블에는 단일 대리 키 열이 있으므로 잘 작동합니다.

이를 수행하는 방법에는 여러 가지가 있습니다. 내가 가장 좋아하는 방법은 다음과 같습니다.

  1. 을 추가하다 mod_user 소스 테이블에 필드 (로그를 작성하려는 것).

  2. 로그하려는 필드가 포함 된 로그 테이블을 작성하고 log_datetime 그리고 seq_num 필드. seq_num 기본 키입니다.

  3. 모니터링 된 필드가 변경 될 때마다 현재 레코드를 로그 테이블에 삽입하는 소스 테이블에 트리거를 만듭니다.

이제 당신은 모든 변화에 대한 기록을 가지고 있고 누가 그것을 만들었습니다.

일반적으로 사용자 정의 감사 (다양한 테이블 생성)는 나쁜 옵션입니다. 일부 로그 활동을 건너 뛰기 위해 데이터베이스/테이블 트리거를 비활성화 할 수 있습니다. 사용자 정의 감사 테이블을 변조 할 수 있습니다. 응용 프로그램을 중단 할 예외가 발생할 수 있습니다. 강력한 솔루션을 설계하는 데 어려움을 겪지 않습니다. 지금까지 나는이 토론에서 매우 간단한 사례를 본다. 현재 데이터베이스 및 권한있는 사용자 (DBA, 개발자)와 완전히 분리해야합니다. 모든 주류 RDBMS는 DBA조차도 비활성화 할 수없는 감사 시설을 제공합니다. 따라서 RDBMS 공급 업체의 감사 기능이 첫 번째 옵션이어야합니다. 다른 옵션으로는 제 3 자 트랜잭션 로그 리더 또는 사용자 정의 로그 리더가 있는데, 이는 일부 형태의 감사 데이터웨어 하우스 또는 실시간 이벤트 핸들러가 끝나는 메시징 시스템으로 분해 된 정보를 메시징 시스템으로 푸시합니다. 요약 : Solution Architect/"Data Architect on Data Architect"는 요구 사항을 기반으로 이러한 시스템을 정리해야합니다. 일반적으로 솔루션을 위해 개발자에게 넘겨주기에는 너무 심각한 것입니다.

분리 원리에 따라 :

  1. 감사 데이터 테이블은 기본 데이터베이스와 분리되어야합니다. 감사 데이터베이스는 많은 과거 데이터를 가질 수 있으므로 메모리 활용 관점에서이를 분리하는 것이 합리적입니다.

  2. 트리거를 사용하여 전체 데이터베이스를 감사하지 마십시오. 지원할 다른 데이터베이스가 혼란스러워지기 때문입니다. DB2, SQLSERVER, MYSQL 등에 하나를 작성해야합니다.

파티에 늦었지만 나는 강력히 추천합니다. Autoaudit 프로젝트.
100% 무료 및 오픈 소스입니다. SQL MVPS Paul Nielsen과 John Sigouin이 저술했습니다. 매우 안정적이며 현재 버전 3.30에 있습니다.

설치가 간단합니다. 그들이 제공하는 SP를 실행하십시오. 감사 스키마, 일부 유지 보수 SP 및 감사에 필요한 트리거가 생성됩니다. 거기에서 감사하려는 테이블과 세부 사항을 선택하십시오.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top