모든 DB 테이블에 생성 날짜 및 마지막 업데이트 날짜 필드를 포함하여 표준화하는 것이 합리적입니까?

상사는 현재 팀에 일부 개발 표준을 적용하려고 시도하고 있기 때문에 어제 회의에서 그녀가 자라기 전까지는 잘 진행되고있는 표준에 대해 논의했습니다.

• 모든 DB 테이블에는 트리거에 의해 업데이트 된 CreatedDate 및 LastUpdatedDate 열이 있습니다.

이 시점에서 우리 팀은 의견 편견에 시달렸습니다. 우리 중 절반은 모든 테이블에서이 작업을 수행하는 것이 이익이 거의없는 많은 양의 작업이라고 생각합니다 (우리는 고정 예산 프로젝트에서 작업하므로 모든 비용은 회사의 이익에서 비롯됩니다). 하반기는 그것이 프로젝트 지원에 도움이 될 것이라고 믿는다.

나는 전 캠프에 단단히있다. 일부 외부 사례로 인해 추가 컬럼이 지원 가능성을 향상시킬 수 있음을 이해하지만 유지 보수뿐만 아니라 처음에 컬럼을 추가하는 데 필요한 작업량으로 인해 더 많은 시간을 소비 할 수 있습니다. 단위 테스트 또는 부하 테스트와 같은 중요한 것들. 또한 이러한 추가 열로 인해 ORM을 사용하기가 더 어려워 질 것이라고 확신합니다. 주로 C #과 Oracle을 사용한다는 점을 염두에 두십시오.

그래서 내 질문은 두 가지입니다.

• 내가 올바른 캠프에 있습니까? 나는 세계적으로 유명한 데이터베이스 기술을 가지고 있다고 주장하지 않기 때문에 부작용이없는 사소한 쉬운 추가 일 수 있습니다.
• 표준에 관한 회의가 슬래 깅 경기로 진행되는 상황을 어떻게 처리 하시겠습니까? 이 표준이 장기적으로 우리에게 도움이되지 않는다는 것을 어떻게 실제로 판매 할 수 있습니까?

지원 가능성이 주요 이점이라고 말하지는 않지만 이것은 상당히 일반적인 관행입니다. 이 방법의 실질적인 이점은 감사 추적을 유지하는 것입니다. 또한 마지막으로 업데이트 한 사용자의 사용자 이름이 포함 된 추가 열이있는 것이 일반적입니다.

모든 종류의 재무 또는 감각적 데이터를 다루는 경우 PCI 및 SOX 규정 준수에 대해 들어 보셨을 것 입니다. 이러한 사양을 충족하려면 포괄적 인 감사 추적이 필요합니다.

면책 조항 : 그러나 데이터베이스 감사 추적을 달성하는 훨씬 더 좋은 방법이 있습니다> https : //.com/questions/1051449/ideas-on-database-design-for-capturing-audit-trails

몇 가지 데이터베이스 유지 시간 소인 필드를 일련의 테이블에 추가하는 것은 어려운 작업이 아니기 때문에 이전 인수는 유효하지 않습니다. 이것은 실제로 후배 나 인턴에게주는 일종의 정신 마비 과제이며, 그들은 2 주 동안 단 한 번의 스프린트로 쉽게 할 수 있습니다.

단순히 응용 프로그램 사용자가이 필드를 수정하지 못하게하고 유지 보수 및 디버깅에 유용하며 비즈니스 로직에는 거의 사용하지 않기 때문에 ORM에 이러한 필드를 맵핑해야 할 수도 있고 필요하지 않을 수도 있습니다. 나는 두 가지 방법으로 모두 상점에서 일했고 솔직히이 방법에 대해 많은 의견을 가지고 있지 않습니다.

데이터베이스 수준에서 이러한 기능을 구현하는 데있어 확장 된 기능이 여전히 인적 비용을 능가하는 이점은 물론, 프로젝트의 총체적인 두뇌력보다 회의를 가로 채서 장엄한 가슴 뛰기 경기에서 스파링하는 것보다 훨씬 적을 것입니다. 몇 시간의 회의가 프로젝트 수명에 미치는 영향을 집계 할 때 비용이 많이 든다는 사실에 놀라지 않을 것입니다. 모든 사람들이 모인 시간당 임금과 혜택을 상상 해보자.

... 사람이 결정적인 진술을할수록 자신이 결정적으로 잘못 될 가능성이 높아집니다.-tyler durden

이것은 블랭킷 "표준"에 적용되는 반면, 일부 테이블에서는 큰 승리가 될 수 있지만, 모든 테이블에서 유지 보수 또는 유지 보수를 잊어 버리는 불필요한 소음과 더 많은 코드 일 가능성이 높습니다.

여기에 있어야 할 균형이 있습니다. 그것이 의사 결정자들에게 푸시해야 할 것입니다.

나는 전적으로 동의합니다. 모든 데이터베이스의 거의 모든 테이블에는 작성 날짜 및 업데이트 날짜 필드가 2 개 이상 있어야 합니다 . 작성 날짜와 업데이트 날짜를 넣어야하는 이유는 여러 가지가 있습니다. 명백한 이유 때문에 이전 사람들이 말한 것은 ... 감사입니다.

저는 25 년 동안 시스템과 데이터베이스를 설계 해 왔으며 수백 명의 클라이언트에서 근무했습니다. 이것을 필요로하지 않는 단일 클라이언트는 없습니다.

이를 수행하는 두 가지 기본 방법이 있습니다.

1-첫 번째 연습은 데이터베이스가 작업을 수행하고 테이블 디자인에 직접 넣는 것입니다. 가장 적은 것은 어느 것이나 추천합니다.

2-내가 선호하는 다른 방법은 이것을 처리하기 위해 복제 도구를 사용하는 것입니다. DEV 팀에게는 오버 헤드가 적고 비용이 없습니다. 그러나 도구는 비싸다. 이 유형의 도구를 사용하면 삭제 프로세스를 훨씬 쉽게 감사 할 수 있다는 이점이 있습니다. 복제 도구가 없으면 감사 테이블을 작성하고 삭제를위한 트리거를 작성해야합니다. 제 생각에는 좋지 않습니다.

이러한 필드를 갖는 또 다른 이점은 모든 OLTP 시스템을 위해 항상 구축 된 데이터웨어 하우스 및 ODS입니다. 증분 데이터가 없으면 효과적으로 데이터를 가져올 수 없습니다. 그렇지 않으면 매일 전체 DB를 다시로드해야 할 위험이 있습니다.

이 두 날짜를 입력해야하는 다른 많은 비즈니스 이유가 있습니다. 여기서는 다루지 않겠습니다. 숙제를하고 3-6-12-48 개월이 지나면이 두 가지 간단한 분야에 참여하게되어 매우 기쁠 것입니다.

가능한 경우 두 솔루션을 모두 구현하고 일반적으로 권장합니다.

데이터베이스에 날짜를 생성하고 열을 기준으로 생성했으며 데이터 문제를 추적하는 데 큰 도움이되었습니다. 되돌릴 필요가있는 경우 전체 감사 테이블에서 올바른 레코드를 찾는 데 도움이됩니다 (매우 큰 테이블의 위치를 ​​알기 때문에). 열을 작성하여 수정해야합니다. 전체 감사가없는 경우 특히 누가 데이터를 넣는 지 알면 도움이됩니다.

어떤 형식이나 다른 형식의 감사가 필요없는 Enterprise 응용 프로그램이 없다고 생각할 수 있습니다. 분명히 상사는 비교적 가벼운 감사 만 필요하다고 생각합니다. 개인적으로 회사가 의존하는 데이터가 포함 된 모든 데이터베이스에 대해 전체 감사를 선호합니다 (백업을 복원하는 것보다 감사 테이블에서 2000 개의 잘못된 레코드를 되 돌리는 것이 훨씬 쉽습니다). 이런 종류의 일은 사기를 저지르는 사람들을 잡는 데 도움이됩니다. 모든 감사는 데이터베이스 레벨에 있어야합니다.

이 데이터가 어떻게 도움이됩니까? 먼저 이전 데이터를 찾아 볼 때를 좁히고 (수정판) 데이터를 입력 할 때 활성화 된 프로그램 버전을 확인할 수 있습니다. 따라서 2011 년 7 월 6 일에 출시 된 버전 2.3에서 해당 문제를 해결 한 다음 8 월 7 일에 레코드가 삽입 된 것과 동일한 문제를 발견했다면 해결 방법이 좋지 않았을 수 있습니다. 이전 데이터로 되돌려 야하는 경우 전체 감사가없는 경우 이전 데이터를 찾을 수있는 백업 버전을 알려줍니다.

개발자는 시간이 지남에 따라 데이터를 유지 관리해야하며 잘못된 데이터를 누군가가 수정해야한다고 생각하지 않는 것 같습니다. 그런 일을하는 것은 그러한 일을해야하는 사람들에게 매우 가치가있을 수 있습니다. 그녀가 감사에 충분하다고 생각하지는 않지만 상사가 옳습니다. 이 열과 트리거를 추가하는 데 걸리는 매우 적은 시간을 정당화하기 위해 해결하기 쉬운 하나의 심각한 문제가 필요합니다.

워크로드는 스크립트로 작성하여 생성 할 모든 데이터베이스에 적용 할 수 있기 때문에 문제가됩니다. 트리거와 함께 모든 테이블에 열을 추가하십시오. 빌드와 함께 실행해야한다는 것을 기억해야합니다.

고객이 원하는 한, 고객이 원하는대로 앱에 통합하도록 비용을 지불하도록 할 수 있습니다. 많은 사람들은 누가 언제 마지막으로 그것을 만들고 변경했는지와 같은 추가 정보를보고 싶어합니다. 알거나 거짓말을하기 위해 모든 사람에게 이메일을 보낼 필요가 없습니다. 누군가 레코드를 볼 때마다 로그를 쿼리하지 않아도됩니다.

데이터베이스에 넣는 것이 어려울 수 있으므로 필드를 활용하는 추가 기능에 대한 비용을 청구하거나 시스템을 사용하는 클라이언트의 양에 대한 피드백을 제공 할 수 있습니다.

이것은 구현하기에 상당히 사소한 것일 수 있습니다 (총 1 ~ 3 일), 평생 동안 응용 프로그램에 얼마나 많은 가치가 있는지 생각합니다.

먼저, 열을 추가하려면 alter table 문이 필요하고 alter table은 모두 동일합니다 (테이블 이름 제외). 필요한 모든 테이블에 대해 alter SQL 문을 생성하는 스크립트를 작성할 수 있습니다. . NULL이 기존 데이터를 설명하고 컬럼의 존재를 점검하여 다시 실행할 수 있도록해야합니다.

둘째, 열의 경우 GetUTCDate () (SQL Server, Oracle과 다를 수 있음)와 같은 기본값을 사용하면 삽입시 코딩 추가 사항이 해결되므로 기본값이 다음과 같이 삽입 코드에 대해 코드베이스를 변경할 필요가 없습니다. 익숙한.

업데이트 트리거로 데이터 업데이트 (마지막 수정으로 변경)를 해결할 수 있습니다. 이 트리거는 모든 테이블에서 거의 동일하므로이 트리거 코드 (SQL)는 기존 테이블에 대해 코드를 생성 할 수 있습니다.

잠재적으로 많은 SQL 스크립트 코드가있을 수 있지만 (테이블 수에 따라 다름) 반복 가능한 패턴이므로 기존 DB 스키마를보고 코드를 생성 할 수 있습니다.