여러 엔티티 클래스, 사용자, 고객, 포스트 등이있다SQL - 테이블 디자인 - DateCreated 및 DateUpdated 열을 내 응용 프로그램에 대한
나는 데이터베이스를 설계하려고 해요나는 경우 날짜를 저장할 엔티티가 작성되고 갱신되었습니다. 이것은 까다로워지는 곳입니다. 물론 하나의 옵션은 각각의 엔티티 테이블에 대해 created_timestamp 및 update_timestamp 열을 추가하는 것입니다.하지만 그건 저급하지 않습니다.
또 다른 가능성은이 정보를 저장하는 로그 테이블을 만드는 것일 수 있으며 엔티티의 업데이트 추적을 포함하도록 만들 수 있습니다.
의견이 있으십니까? 나는 후자를 구현하는데 기대고있다.
단일 로그 테이블은 하를 위해 모든 테이블 접근 방식은 내가 생각할 수있는 두 가지 문제가 있습니다
CreatedDate 및 ModifiedDate 열은 각 테이블에 정의되어 있기 때문에 중복되지 않습니다. 그 방법을 고수하고 각 테이블에 삽입 및 업데이트 트리거를 넣어 해당 열을 채 웁니다. 변경 작업을 수행 한 최종 사용자를 기록해야하는 경우 트리거를 건너 뛰고 응용 프로그램 코드에서 타임 스탬프와 사용자 필드를 채 웁니다.
얼마나 자주 생성/업데이트 된 타임 스탬프를 프리젠 테이션 계층에 포함시켜야합니까? 대답이 "훌륭한 위대한 시대에 한 번 이상"이라면, 나는 각 테이블에 그 칼럼을 갖는 것이 더 나을 것이라고 생각합니다.
"로그"또는 "이벤트"테이블을 사용하여 후자를 처리합니다. 내 경험에 의하면, "업데이트 된"타임 스탬프는 매우 빠르며, 가장 최근의 업데이트 시간뿐만 아니라 원하는 곳에서 많은 시간을 할애 할 수 있기 때문입니다.
2 년 전에 작업 한 프로젝트에서 트리거 테이블을 구현하여 감사 테이블 (변경 사항에 대한 기본 정보, 테이블 당 하나의 감사 테이블)을 업데이트했습니다. 여기에는 수정 된 날짜 (및 마지막으로 수정 된 날짜)가 포함됩니다.
키 테이블 (조인 또는 참조 데이터 테이블 제외)에만 적용되었습니다.
이것은 LastCreated & LastModified 필드를 설명해야한다는 일반적인 좌절감을 없애고 트리거를 최신 상태로 유지하는 성가심을 도입했습니다.
결국 트리거/감사 테이블 디자인이 잘 작동하고 ETL (!) 전에 트리거를 제거하고 다시 적용해야한다는 것을 기억해야합니다.
저는 웹 기반 CMS입니다.대부분의 페이지에는 생성 날짜와 마지막으로 업데이트 된 날짜가 표시되며 마지막으로 생성 된 (업데이트 된) 페이지 목록이 표시됩니다. 관리 인터페이스에서도이 정보를 사용합니다.