각 데이터베이스 테이블에 대한 공통 감사 열은 무엇입니까?

Question

'status', 'date_created', 'date_updated'를 데이터베이스의 모든 테이블에 포함하려고합니다. 'status'는 소프트 삭제를위한 것입니다.

다음으로 'user_created', 'user_updated'열을 각 테이블에 추가하는 사용자는 거의 없습니다.

해당 열을 추가하면 모든 테이블에 대해 적어도 5 개의 열을 갖게됩니다. 오버 헤드가 너무 많습니까?

다섯 열을 사용하는 것이 좋습니다.

또한 'user_created'의 'user'는 데이터베이스 사용자를 의미합니까? 또는 응용 프로그램 사용자?

Answer 1

위의 설명에 따라 실제로 필요한 테이블에만 감사를 추가하는 것이 좋습니다.

일반적으로 응용 프로그램 사용자를 감사하려고합니다. 웹 또는 SOA와 같은 응용 프로그램이 동일한 자격 증명을 가진 모든 사용자를 연결하는 경우가 많으므로 DB 로그인을 저장하는 것은 의미가 없습니다.

IMHO, date created/last date updated/lastupdateby 패턴은 전체 사진을 제공하지 않습니다. 마지막으로 변경 한 사람과 변경된 사항 만 볼 수 있기 때문입니다. 감사를 수행하는 경우 감사 대신 trigger과 같은 패턴을 사용하여 전체 변경 감사를 수행하는 것이 좋습니다. 표 삽입, 업데이트/삭제가 캡슐화되어 있으면 트리거를 사용하지 않아도됩니다. Stored Procedures을 통해 사실, 감사 테이블은 매우 커질 것이지만, 일반적으로 마녀 사냥에 많이 걸리지는 않으며 아카이브 될 수 있고 날짜별로 쉽게 파티션 될 수 있습니다 (읽기 전용으로 만들 수 있음). 분리 된 감사 테이블을 사용하면 DateCreated 또는 LastDateUpdated 열은 필요하지 않으므로이를 파생시킬 수 있습니다. SQL은 응용 프로그램 사용자를 파생시킬 수 없기 때문에 일반적으로 최종 변경 사용자가 필요합니다.

논리적 삭제를 결정하면 프로세스 상태를 모델링하는 테이블 (예 : 지불 상태 등)이있을 가능성이 있으므로 논리적 삭제를 나타내는 필드로 '상태'를 사용하지 마십시오.) ActiveYN 또는 IsActive과 같은 bit 또는 char 필드를 사용하면 논리적 삭제가 일반적입니다.

모든 쿼리가 레코드를 필터링해야하고, 트랜잭션 테이블의 삭제 된 레코드를 유지하면 이러한 테이블을 특히 Many : Many/junction 테이블에서 더 크게 만들 수 있으므로 논리 삭제가 번거로울 수 있습니다. 2 상태 필드는 인덱스에서 유용 할 정도로 선택 적이기 때문에 성능에 영향을 미칠 수 있습니다. 이 경우 전체 감사를 통한 실제 삭제가 더 적합 할 수 있습니다.

Answer 2

간단한 답변 - 데이터베이스에 필요한 것만 데이터베이스에 저장하십시오.

Answer 3

전 5 가지를 모두 사용했습니다. 웹 앱을 통해 누가 레코드를 만들고 (마지막으로) 편집했는지 추적하고 싶을 때 타임 스탬프와 로그인 한 사용자를 포함시킵니다 (그러나 DB 사용자는 아니며 시스템이 설정되는 방식이 아닙니다. 우리는 모든 DB 상호 작용을 위해 하나의 계정을 사용합니다).

마찬가지로 상태는 사용자가 레코드의 상태를 변경하는 경우에도 유용 할 수 있습니다. "온라인"에서 "오프라인"에서 "아카이브"로 이동하면 해당 레코드에 반영 될 수 있습니다.

그러나 모든 테이블에서이 값을 사용하지는 않으며 사용자도 그러지 않아야합니다. 때로는 레코드의 일부만 저장하는 테이블 (normalized)이 있거나, 누가 만든 상태 나 시간이 필요한 값이없는 테이블이 있습니다.

모든 테이블에 대해 고려해야 할 사항은 기본 키 필드입니다. 접근하는 방식이 사운드보다 더 정교하지 않으면, 거의 항상 하나가 필요합니다. 어떤 것들은 반드시 하나를 필요로하지는 않습니다 (예를 들어, 상태 목록은 Unique the abbreviation 일 수 있습니다). 그러나 이는 일련의 타임 스탬프 및 상태 필드보다 테이블의 대부분에서 더 중요합니다.