2009-07-08 9 views
3

저는 직원 목표 웹 응용 프로그램을 작성 중입니다.데이터베이스 아카이브 대 시간대 기반 테이블/필드

리드/관리자는 팀 구성원과 논의한 후에 팀 구성원을위한 목표를 설정합니다. 이것은 조직이 따르는 감정주기에 따라 매년/반년/분기입니다.

이제는 기간 기반 필드를 추가하거나 이전 분기/년 데이터를 보관하는 것이 더 좋은 방법입니다. 사용자가 이전 목표 (너무 자주 활동하지 않음)를보고 싶을 때 해당 날짜에 속한 아카이브를 임시 테이블에 복원하여 직원에게 보여줄 수 있습니다.

포인트

보관에 시작 : 데시벨 크기, 간단한 DB 쿼리의 결과를 감소, 누군가가 오래된 데이터를 볼려고 오버 헤드가 추가됩니다.

시간 기간 기반 필드/테이블 : 쿼리에서 하나 이상의 추가 조인, 이전 데이터가 현재 데이터와 유사하게 처리되므로 이전 데이터를 검색하는 데 오버 헤드가 발생하지 않습니다.

추신 : 성능면에서 최적화를 달성 할 수 있다면 공간 비용이 들지 않습니다. 이는 웹 앱이며 최고 시간대에 조직의 모든 직원이보고/업데이트 할 것이기 때문입니다. 그래서 기간을 제거하면 내 쿼리가 훨씬 간단 해집니다. 감사합니다.

답변

1

기간 필드를 추가하고 크기가 문제가 될 때까지 기다리는 것으로 시작합니다. 설명하는 데이터의 종류는 많은 저장 공간을 소비하는 것처럼 들리지 않습니다.

제어 할 수 없을 정도로 커지면 나중에 아카이브 접근 방식을 볼 수 있습니다. 그러나 코딩은 단순히 관련 기간을 데이터와 함께 저장하는 것보다 훨씬 오래 걸릴 것입니다.

+0

시간 필드를 제공하지 않는 장점은 삽입/업데이트/삭제와 관련된 쿼리가 훨씬 간단해진다는 것입니다. 따라서 우리는 향상된 성능과 확장 성을 얻을 수 있습니다. –

1

사용자가 이전에 임의로 멀리 볼 수 있다는 요구 사항이있는 경우 실제로 데이터에 액세스 할 수 있어야합니다.

이것은 단지 지속되지 않습니다 : 해당 날짜에 속하는 아카이브가 일부 임시 테이블 복원 및 직원에 표시 될 수 있습니다

.

내 생각에 정기적으로 (꼭 필요한 경우 읽음) '매우 오래된'데이터를이 테이블의 다른 테이블로 이동하는 것이 좋습니다. 이 시점에서 디스크 공간은 매우 저렴하므로 데이터를 보존하는 것은 임의의 시간으로 돌아가 아카이브를 복원 할 수있는 시스템을 구현하는 것만 큼 비싸지 않습니다.

+0

공간 비용은 아닙니다. 성능 측면에서 몇 가지 최적화를 달성 할 수 있다면 요점은 웹 앱이며 최고 시간대에는 조직의 모든 직원이 찾고있을 것이기 때문입니다/업데이트. 그래서 기간을 제거하면 내 쿼리가 훨씬 간단 해집니다 :) –

3

로깅 유형 데이터와 달리 시간이 지남에 따라 변경되는 데이터에 대한 내용을 가정 할 때 필자가 선호하는 방법은 기본 테이블에 "최신"버전의 데이터 만 보관하고 이전 버전의 데이터를 아카이브 테이블에 자동으로 복사합니다. 이 아카이브 테이블은 타임 스탬프와 같은 버전 필드를 추가하여 기본 데이터베이스를 미러링합니다. 이 아카이브는 트리거를 사용하여 수행 할 수 있습니다.

이 접근법에서 볼 수있는 가장 큰 이점은 데이터베이스 디자인을 손상시키지 않는다는 것입니다. 특히, 버전 필드를 통합하는 복합 키를 사용하는 것에 대해 걱정할 필요가 없습니다. 실제로 키가 데이터베이스에서 허용하지 않는 시간 기반 필드를 사용합니다.

이전 데이터로 이동해야하는 경우 아카이브 테이블에 대해 select를 실행하고 쿼리에 버전 제약 조건을 추가 할 수 있습니다.

+0

그래, 그게 내 요점 이었어. 다른 의견을 갖고 싶었습니다. 감사!! –