내 응용 프로그램 내에서 감사 로깅을위한 최선의 방법을 결정하려고합니다. 로그의 주요 원인은 이벤트의 순서 (변경 사항)를보고하는 것입니다.감사 로깅 전략
나는 Object의 계층 구조를 가지고 있기 때문에 후반부에 계층 구조의 일부에서 무언가가 변경되면 보고서를 만들어야합니다.
는 내가 세 가지 옵션이 있다고 생각합니다.
나는 현재 옵션 1.
쪽으로 생각이 기울고 있어요 감사 로그는 이러한 이벤트, 어떤 이벤트가있었습니다을 수행 발생한 이벤트의 연대기 목록은 기본적으로.
평면 뷰는 쉽게 주문하고 쿼리 할 수 있으므로 더 좋을 것이라고 생각합니다. 그래서 저는 여러분의 옵션 # 2/# 3쪽으로 더 기울고 있습니다.
트랜잭션 유형, 시간, 사용자 ID, 변경된 사항에 대한 설명 및 제품과 관련된 기타 관련 정보를 포함하십시오.
시간이 지남에 따라 제품을 추가 할 수도 있으며 감사 로그 모듈을 계속 수정할 필요가 없습니다.
감사 용도로 사용하는 경우 동일한 db의 테이블/테이블 대신 실제 추가 전용 매체를 사용합니다.
변경 내역의 용도로 제안합니다.이 경우 현재 상태가 아닌 실제 이벤트를 기록하기 위해 응용 프로그램/db를 재구성합니다.
모든 감사 항목에 대해 하나의 테이블을 만듭니다 (2) 및 (3)과 함께 갈 것입니다.
추가 작업을 병합해도 성능에 영향을주지 않으면 평면 뷰가 좋습니다.
이 문제를 해결하기 위해 AOP 프레임 워크를 살펴볼 수 있습니다. 모든/모든 메소드의 시작 또는 끝에 로깅 기능을 삽입 할 수 있습니다. 이 길을 따라 가면 로그 데이터를 저장하는 것이 무엇인지 정의하는 데 도움이 될 수 있습니다.
나이가 들더라도이 주제와 이야기해야합니다.
감사 테이블이 하나만있는 것은 일반적으로 좋지 않습니다. 데이터베이스에 잠금 문제가 생기면 모든 테이블에 접근 할 수 있기 때문입니다. 각 테이블마다 별도의 감사 테이블을 사용하십시오.
응용 프로그램에서 감사를 수행하는 것도 좋지 않습니다. 감사는 데이터베이스 레벨에서 수행되어야하며 그렇지 않으면 일부 정보가 손실 될 위험이 있습니다. 대부분의 데이터베이스에서는 응용 프로그램의 데이터 만 변경되지 않습니다. 어느 누구도 사용자 인터페이스에서 한 번에 하나씩 모든 제품의 가격을 변경할 예정입니다. 사용자 인터페이스에서 10000000000 개까지 모두 10 % 증가해야합니다. 감사는 일부 변경 사항을 포착해야합니다. 이 작업은 대부분의 데이터베이스에서 트리거로 수행해야합니다 (SQL Server 2008에는 감사 기능이 내장되어 있습니다).가능한 가장 나쁜 잠재적 변경 사항 (직원이 사기를 저 지르거나 악의적으로 데이터를 파괴하려는 경우)은 특히 응용 프로그램이 아닌 다른 곳에서 자주 발생합니다 (특히 재무 데이터베이스 나 테이블에 포함하지 않아야하는 사용자에 대한 테이블 수준 액세스 허용). 개인 정보). 응용 프로그램에서 감사를 수행하면이 내용이 적용되지 않습니다. 개발자는 데이터를 보호 할 때 외부 소스 만이 유일한 위협이된다는 사실을 종종 잊어 버립니다.
@HLGEM : +1 일반적으로 나는 당신에게 동의합니다. 나의 특정한 상황을 위해, 재정적 인 힘 감사를 요구하지 않았다. 변경된 사항은 변경 사항이 적용되는 유일한 장소이기 때문에 두 개의 테이블로 변경된 내용과 응용 프로그램을 통해서만 변경 사항을 기록해야했습니다. 나는 그것이 YAGNI의 경우라고 생각한다. –
그래서 트랜잭션 기반 접근 방식을가집니다. 즉, 버전 번호뿐 아니라 엔티티 ID가 있습니까? –