기록 테이블의 장단점 - 트리거, sproc 또는 애플리케이션 수준 사용 [닫기]

Question

나는 현재 내 데이터베이스의 일부 테이블에 대한 기록 테이블을 가지고 있다는 아이디어를 가지고 놀고 있습니다.기본적으로 나는 수정된 날짜와 업데이트, 삭제 및 삽입과 같은 수행된 작업을 저장하는 작업 열이 있는 해당 테이블의 복사본과 기본 테이블을 가지고 있습니다.

지금까지 나는 기록 테이블 작업을 수행할 수 있는 세 가지 다른 장소를 생각할 수 있습니다.

• 업데이트, 삽입 및 삭제를 위해 기본 테이블에서 트리거합니다.(데이터 베이스)
• 저장 프로시저.(데이터 베이스)
• 애플리케이션 레이어.(애플리케이션)

내 주요 질문은 이러한 각 레이어에서 작업을 수행할 때의 장점, 단점 및 장점이 무엇인지입니다.

트리거 방식을 사용함으로써 제가 생각할 수 있는 한 가지 장점은 데이터베이스 위에 어떤 프로그램이 구현되더라도 무결성이 항상 유지된다는 것입니다.

Answer 1

이런 식으로 넣을 것입니다.

• 저장 Procs : 테이블을 직접 수정하면 우회합니다. 데이터베이스의 보안은이를 제어 할 수 있습니다
• 신청: 같은 거래. 또한 여러 언어로 여러 응용 프로그램이있는 경우 각 스택에서 구현해야하며 다소 중복됩니다. 그리고
• 트리거 : 응용 프로그램에 투명하며 모든 변경 사항을 캡처합니다. 이것은 내가 선호하는 방법입니다.

Answer 2

트리거는 간단한 기록을 달성하는 가장 빠르고 쉬운 방법입니다.다음 정보는 내역 처리에 일부 비즈니스 규칙이 포함될 수 있고 추적 중인 테이블에서 찾을 수 없는 로깅 정보가 필요할 수 있는 보다 복잡한 예를 가정합니다.

트리거는 우회할 수 없기 때문에 sproc보다 안전하다고 생각하는 사람들에게 나는 그들이 다음과 같은 가정을 하고 있다는 점을 상기시켜 줍니다.

!) 사용자가 DISABLE TRIGGER를 실행하지 못하도록 하는 권한이 존재합니다. [그러나 엔터프라이즈 애플리케이션의 일반적인 패턴인 sprocs에 대한 EXECUTE를 제외하고 데이터베이스에 대한 모든 액세스를 제한하는 권한도 존재할 수 있습니다.] 따라서 올바른 권한을 가정해야 하며 따라서 sprocs는 동일합니다. 보안 및 우회 가능성 측면에서 트리거

!) 데이터베이스에 따라 트리거를 실행하지 않는 업데이트 문을 실행하는 것이 가능할 수도 있습니다.중첩된 트리거 실행 깊이에 대한 지식을 활용하여 트리거를 우회할 수 있습니다.유일하게 확실한 솔루션에는 데이터베이스 보안과 승인된 메커니즘(트리거, sproc 또는 데이터 액세스 계층 등)만 사용하여 데이터에 대한 액세스를 제한하는 것이 포함됩니다.

나는 여기서 선택이 분명하다고 생각합니다.여러 애플리케이션에서 데이터에 액세스하는 경우 가장 낮은 공통 계층에서 기록을 제어하려고 하며 이는 데이터베이스를 의미합니다.

위의 논리에 따라 트리거 또는 저장 프로시저의 선택은 저장 프로시저가 가장 낮은 공통 계층인지 여부에 따라 달라집니다.성능과 부작용을 더 잘 제어할 수 있고 코드를 유지 관리하기가 더 쉽기 때문에 트리거보다 sproc을 선호해야 합니다.

트리거는 허용되지만 업데이트되는 테이블 외부의 데이터를 읽어 잠금을 늘리지 않도록 하십시오.로그 테이블에 삽입하도록 트리거를 제한하고 필요한 것만 기록하십시오.

애플리케이션이 공통 논리적 액세스 계층을 사용하고 시간이 지나도 이것이 변경될 가능성이 없는 경우 여기에 논리를 구현하는 것을 선호합니다.책임 체인 패턴과 플러그인 아키텍처를 사용하고 이를 종속성 주입에서 구동하여 완전히 다른 유형의 기술, 다른 데이터베이스, 기록 서비스 또는 기타 필요한 모든 것에 대한 로깅을 포함하여 기록 모듈에서 모든 처리 방식을 허용합니다. 상상할 수 있었다.

Answer 3

수년간 방아쇠 기반 접근 방식을 사용해 왔으며 우리에게 확실히 잘 작동했지만 다음과 같은 점을 숙고 할 사항이 있습니다.

1. 심하게 사용되는 (예 : 멀티 테넌트 SaaS 기반 응용 프로그램)의 트리거는 매우 비쌀 수 있습니다.

2. 일부 시나리오에서는 몇 가지 필드가 중복 될 수 있습니다. 트리거는 기록 할 필드에서 맑은 경우에만 양호합니다. 응용 프로그램을 사용하면 "구성"을 기반으로 특정 필드를 기록하는 데 도움이되는 인터셉터 레이어가있을 수 있습니다. 비록 오버 헤드의 자체 몫이지만

3. 적절한 데이터베이스 제어가 없으면 사람은 트리거를 쉽게 비활성화하고 데이터를 수정하며 트리거를 활성화 할 수 있습니다. 경보를 올리지 않고 모두

4. 풀에서 연결되는 웹 애플리케이션의 경우 풀에서 연결되는 경우 변경 사항을 변경 한 실제 사용자를 추적하는 것이 지루할 수 있습니다. 가능한 솔루션은 모든 트랜잭션 테이블에 "편집 된"필드를 갖는 것입니다.

Answer 4

늦었지만 고려할 수있는 몇 가지 옵션이 추가됩니다.

데이터 캡처 변경 : 이것 기능은 SQL Server 2008 R2+에서만 사용할 수 있지만 Enterprise Edition에서만 제공됩니다. 추적하려는 테이블을 선택할 수 있으며 SQL Server가 작업을 수행합니다. 트랜잭션 로그를 읽고 데이터를 사용하여 히스토리 테이블을 채워서 작동합니다.

트랜잭션 로그 읽기 : 데이터베이스가 전체 복구 모드에 있으면 트랜잭션 로그를 읽고 거의 트랜잭션에 대한 세부 사항을 찾을 수 있습니다.

단점은 기본적으로 지원되지 않는다는 것입니다. 옵션은 fn_dblog 또는 다음과 같은 타사 도구와 같은 문서화되지 않은 기능을 사용하여 트랜잭션 로그를 읽는 것입니다. ApexSQL 로그.

트리거 : 관리 할 트리거가 너무 많지 않은 소수의 테이블에는 잘 작동합니다. 감사하려는 테이블이 많으면이를 위해 타사 도구를 고려해야합니다.

이러한 모든 작업은 데이터베이스 수준에서 작동하며 응용 프로그램에 완전히 투명합니다.

Answer 5

트리거는 변경 사항을 캡처하는 유일한 안정적인 방법입니다. 저장된 Procs 또는 앱에서 수행하면 언제든지 로그가없는 변경 사항을 (과도하게) 변경할 수 있습니다. 물론 통나무를 떠나고 싶지 않은 사람은 트리거를 비활성화 할 수 있습니다. 그러나 당신은 오히려 누군가가 그것을 포함하는 것을 기억하기를 희망하는 것보다 로깅을 비활성화하도록 강요하고 싶습니다.

Answer 6

일반적으로 응용 프로그램 계층을 선택하면 앱 코드를 디자인하여 단일 지점에서 로깅을 수행 할 수 있습니다. 다르게 트리거는 모든 테이블에 대해 (DB 기술에 따라) 복제 되었기 때문에 유지하기위한 더 복잡한 접근법입니다. 수백 개의 테이블의 경우 트리거 Coud의 코드 양이 문제가됩니다.

지금 쓰고있는 코드를 유지 관리하는 지원 조직이 있고 누가 코드를 유지 관리 할 것인지 모르고 있다면 (대기업을위한 팁) 응용 프로그램,이 경우 내 의견으로는 역사적 테이블 작업 원칙을 가능한 한 간단하게 만드는 것이 좋습니다. 응용 프로그램 계층은 아마도이 목적에 가장 적합한 장소 일 것입니다.