테이블의 모든 열에 대한 로깅 변경

Question

시스템의 모든 변경 사항을 추적해야하는 시스템을 만드는 중입니다. 즉, 데이터베이스의 열이 변경되면 어떤 테이블, 어떤 열, 변경이 수행되었는지, 어떤 사용자가 어떤 값에서 어떤 값을 알 수 있어야합니다.

필자가 생각한 첫 번째 목적은 column_name, updated_by, updated_on, from_value, to_value (from_value 및 to_value 필드를 단순화를 위해 문자열로 유지)와 같은 필드를 포함하는 로깅 목적으로 각 테이블에 대해 두 번째 테이블을 만드는 것입니다. 그러나 이것은 본질적으로 데이터베이스의 복제본을 생성합니다.

두 번째 옵션은 모든 테이블에 대해 비슷한 유형의 대규모 테이블 (table_name, column_name, updated_by, updated_on, from_value, to_value)을 생성하는 것이지만 관리하기 어려운 테이블이됩니다. 변경 사항이 발생합니다 자주.

두 옵션 모두 동일한 문제가 있으며 테이블 열을 참조하는 방법이 확실하지 않으며 최악의 경우 나중에 응용 프로그램의 수명이 다할 때 열 이름을 어떻게 변경해야합니까?

모든 의견과 제안을 부탁드립니다.

Answer 1

: 디스크 공간의 제약을하지 않을

• 당신은
• 당신이보고 할 수 있어야 적지 않은 데이터 모델을 사용하여 사람이 읽을 수있는 형식의 감사/기록 정보
• 성능 또는 확장 성 요구 사항이 매우 높습니다.
• 감사 데이터 대상은 기술 수준이 아닌 비즈니스 사용자 수준입니다.

그런 경우 내가 아는 가장 좋은 해결책은 디자인에서 "역사"를 일류 개념으로 만드는 것입니다. GregL이 인용 한 link에는 이에 대한 설명이 잘 나와 있습니다. 나의 간단한 구현은 기본적으로 모든 테이블에 "valid_from"및 "valid_until"및 "operator_id"열을 갖고 삭제 작업보다는 "is_valid"를 사용하는 것을 의미합니다.

일반적인 데이터 액세스와 동일한 논리를 사용하여 테이블 간의 모든 관계를 완료하여 기록의 특정 시점에서 데이터의 전체 그림을 만들 수 있기 때문에 별도의 테이블에 대한 변경 사항을 감사하는 것보다 낫습니다. 암호. 즉, 표준보고 도구를 사용하여 "어느 운영자가 식품 카테고리의 모든 제품에 대한 가격을 변경 했습니까?", "1 월 1 일에 100 달러 미만의 제품이 몇 개나 있습니까?"와 같은 질문에 대답하는 보고서를 작성할 수 있다는 의미입니다.

더 많은 공간을 소비하므로 데이터베이스 액세스 논리가 더 복잡해집니다. 또한 ORM 솔루션과 잘 작동하지 않습니다.

Answer 2

이것은 좀 이상하지만 두 번째 기본 키로 각 ​​테이블에 "InsertedOnTimestamp"열을 추가 할 수 있습니다. 그런 다음 사용자가 테이블을 업데이트하고 가장 최근 레코드 만 표시하는보기를 만들 수 없도록하십시오.

Select * From Table 
    Inner Join (Select ID, Max(InsertedOnTimestamp) as LastestRecord From Table Group By ID) as Latest 
    On Table.ID = LatestID AND Table.InsertedOnTimestamp = Latest.LatestRecord 

지옥 같은 messey를 들리지만, 아이디어 없음 덜 ... 난 그냥 기능의 종류에 대한 용어는 "감사"라는 것을 기억

Answer 3

. 그들은 단지했다

http://www.simple-talk.com/sql/database-administration/database-design-a-point-in-time-architecture/

http://www.restfuldevelopment.net/david-kawliche/writing/time-after-time/

Best implementation for fully auditable data model?

http://www.sqlservercentral.com/articles/SQL+Puzzles/anaudittrailgenerator/2067/

: 가치 읽기 수 있습니다 - "데이터베이스 전체 감사를 설계"에 대한 빠른 Google 검색은 다음과 같은 흥미로운 링크를 굴복 나는 "감사"라는 핵심 단어를 알기 때문에 더 나은 링크를 찾을 수 있습니다.

Answer 4

확인 내 answer for the question "history rows management in database" 해당 방법의 장단점에 사용한 솔루션을 설명합니다.

기본적으로 하나의 대규모 테이블이지만 변경 사항은 하나의 문자열 필드에 XML로 기록됩니다.

편집 :

나는 모든 변화는 하나의 XML 문자열이기 때문에, 열 이름을 변경 문제가되지 않았다.
내가 역사를 파헤쳐야했던 대부분의 시간은 "누가 언제 그 특정 레코드를 변경 했나요?"라는 질문이 있었기 때문에 동일한 ID로 적은 수의 레코드를 선택할 수있었습니다.
일부 값이 발생한 모든 레코드를 찾아야하는 경우이 접근법에 문제가 있습니다. 전체 테이블에 대한 전체 텍스트 검색이 필요하며 매우 느립니다.
가능한 검색 시나리오를 분석 한 다음 최상의 솔루션을 선택해야합니다.

고려해야 할 사항이 한 가지 더 있습니다. 즉, 기록 레코드가 변경되지 않으므로 빠른 검색을 위해 색인 레코드의 복사본을 보관할 수있는 다른 데이터베이스를 가질 수 있습니다. 실시간 데이터베이스에서 기록 레코드를 복사하는 자동 서비스를 만듭니다. 내가 여기에 몇 가지 가정을 만들려고