데이터베이스 테이블은 언제 타임 스탬프를 사용해야합니까?

먼저,이 질문이 데이터베이스 교환에 속한다고 생각했지만, 데이터베이스보다는 프로그래밍 솔루션과 전체적으로 더 관련이 있다고 생각합니다. 사람들이 최선이라고 생각하면 데이터베이스 교환으로 이동합니다.

데이터베이스 테이블에 생성 및 업데이트 된 타임 스탬프를 언제 추가해야하는지 궁금했습니다.

첫 번째 명백한 대답은 어떤 비즈니스 로직이 어떤 것이 언제 업데이트되었는지 (트랜잭션 완료 날짜 등) 알아야하는 경우 들어가야한다는 것입니다.

그러나 비 비즈니스 로직 사례는 어떻습니까? 예를 들어 결함 찾기를 돕기 위해 행이 변경된 날짜 시간을 아는 것이 실제로 유용한 시나리오를 생각할 수 있습니다. 오류를 일으키는 다른 행.

이 유스 케이스를 사용하면 모든 테이블에 업데이트를 제공하고 타임 스탬프를 작성하는 것이 좋습니다 (응용 프로그램의 일부로 업데이트되지 않는 가장 사소한 열거 테이블 제외).

모든 테이블에 타임 스탬프를주는 것은 데이터베이스를 신속하게 정리할 수있는 좋은 방법입니다 (잘못된 경우도 있음).

데이터베이스 테이블은 언제 타임 스탬프 생성 및 업데이트를 사용해야합니까?

보다 포괄적 이고 효과적인 데이터베이스 관리 를 위해서는 가장 현명한 방법이 필요합니다.

첫째, 개발자 일 가능성이 높으므로 데이터베이스 트랜잭션 및 / 또는 개발 활동 을 추적하고 데이터베이스와 관련 될 때마다 코드의 버그 및 오류를 쉽게 추적하고 싶을 것 입니다.

또한 통계 목적으로 데이터베이스에서 수행 한 활동을 추적해야 할 때마다 .

또 다른 이유는 아마도 당분간 데이터베이스 활동을 추적 할 필요는 없지만 앞으로는 더 가능성이 높다는 것입니다. 오늘은 시간이 필요하지만 앞으로는 더 많이 사야합니다 .

poacher (개발자)와 gamekeeper (DBA) 모두 인 사람으로서, 나는 여전히 이것의 가치를 보지 못하고 부풀어 오른다 고 생각합니다.

간단히 말해서:

레코드가 추가되었지만 업데이트되지 않은 테이블 (예 : 로그인 등)의 경우 DATE_CREATED 열을 추가하는 것이 좋습니다.

레코드가 추가 및 업데이트되는 테이블의 경우 DATE_CREATED 및 DATE_UPDATED 열을 추가하는 것이 좋습니다.

DATE_CREATED 및 DATE_UPDATED가 기본적으로 디자인의 일부로 모든 테이블에 포함되어있는 여러 곳에서 근무했습니다.

며칠 동안 데이터베이스 업데이트가 실행 된 수백만 / 십억 개의 행이있는 대규모 데이터베이스의 경우 타사 피드, 사용자 업데이트, DBA 수정, 데이터 정리 등

질문의 단어대로, 당신은 물건의 목록을 요구하고 있습니다. 귀하의 질문에 직접 대답하지는 않지만 대체 솔루션을 사용해야 할 때 대답 할 위험이 있습니다.

결함 찾기를 돕기 위해 행이 변경된 날짜 시간을 아는 것이 실제로 유용한 시나리오를 생각할 수 있습니다.

주어진 레코드에 대한 모든 업데이트 로그를 갖는 것이 더 유용합니까? 마지막 업데이트 만 알면 정보가 충분하지 않을 수 있습니다. 이 로그는 별도의 테이블에 넣을 수 있습니다. 동일한 로그 파일에서 여러 테이블의 변경 사항을 추적하는 것이 더 편리합니다 (테이블 일 필요는 없음). 이렇게하면 모든 테이블 change_dates에 대한 대규모 통합 쿼리에서 집계를 얻을 수 없습니다. 또한 시스템에서 더 많은 이벤트를 기록하는 것을 도와줌으로써 문제 해결에 도움이됩니다.

추가로 : 사용자도 고려해야합니다. 그들은 비즈니스 사례가 될 수는 없지만 경험이 부족한 사용자 또는 사용자 오류가 발생하지 않고 항상 컴퓨터에서 비난하려는 기업 문화의 사람들에게는 테이블의 업데이트 날짜를 포함하여 모든 종류의 로깅이 도움이 될 것입니다. 이 경우 Update_UserID 필드도 가질 수 있습니다.

다음 중 하나에 해당하면 데이터베이스 테이블에 작성 및 수정 템플리트가 포함되어야합니다.

1. 이 테이블은 일부 사용자 제공 활동 의 기본 레코드 를 나타냅니다 . 사용자는 X를하지, 당신은 모두가있는 경우 Table_X와 Table_Y의 일대 아이들이있는이 Table_X, Table_Y여분의 필드를 필요로하지 않는다 그래서 차 기록하지 않고.
2. 영구적이거나 일시적이거나 반복적 인 시스템 추적이 필요한 경우 . Table_Y업데이트시 업데이트 만 확인해야하는 경우 Table_X추가 추적 필드가 도움이 될 수 있습니다.

이들 중 어느 것도 독점적 인 것은 아닙니다. 기본적으로 어디에서나 추가 할 수 있으며 성능 조정에 필요할 때만 생략 할 수 있습니다.

개인적인 의견 :

modified열에 값이 표시되지 않습니다 .

created이 생길 않는 한, 절대적으로, 모든 데이터베이스 테이블에 추가해야합니다 뛰어난 그것을 할 수 정당화. 거기에 너무 많은 가치가 있습니다.

그러나 updated낭비로 보인다. 문서 전체를 지정하고 문서 ID와 문서 버전을 지정하는 두 개의 데이터베이스 테이블을 만드십시오. 매우 단순한 경우

create table document (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

create table version (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    document_id INT NOT NULL REFERENCES document(id),
    content TEXT NOT NULL,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

그런 다음 원하는 최신 version을 선택하십시오 document. 이렇게하면 모든 수정 날짜 (마지막 날짜 뿐만 아니라)도 저장 하고 해당 문서의 모든 버전을 유지 합니다. 그것에 대한 유일한 논쟁은 실제로 하드 드라이브 공간이지만, 사용중인 하드 드라이브 공간에 대해 걱정할 때 분명히 대부분의 경우 데이터 버전 관리에 대해 더 귀찮게 합니다