RDBMS 개념 모델은 임시 데이터 버전을 유지하는 데 그리 좋지 않습니다. 이런 점에서 오라클이 부족한 것은 아닙니다.
레코드 수준의 버전 정보를 유지하는 것이 왜 느리다고 생각하는지 분명하지 않습니다. 새 버전을 만드는 데 너무 느립니까? 아니면 정기적 인 작업 중에 데이터 검색에 관해서는 너무 느린가?
다음은 수행 방법입니다.
create table customers
(id number not null primary key
, customer_ref number not null unique key
, name varchar2(30) not null)
/
v 전화 해당하는이과 같습니다 :
을 CUSTOMER_REF의 비즈니스 키 나는 일반적으로 (I 공간의 이유로 축약 구문이 아닌 최선의 방법을 사용하고) 이런 식으로 구축 할 수있는 테이블 고객을 감안할 때
create table customers
(id number not null primary key
, customer_ref number not null
, version_number number
, name varchar2(30) not null
, constraint whatever unique (customer_ref, version_number))
/
이것은 VERSION_NUMBER의 현재 버전을 null로 유지하고 보관시에만 채우는 방식으로 작동합니다. 모든 조회는 and version_number is null을 포함해야합니다. 약간의 어려움이있을 수 있으며 추가로 작성한 색인에이 열을 포함해야 할 수도 있습니다.
분명히 동일한 테이블에 레코드의 모든 버전을 유지하면 성능에 영향을 줄 수있는 테이블 크기가 증가합니다. 오라클의 파티셔닝 옵션은 여기서 확실히 도움이 될 수 있습니다. 또한 내년의 데이터 세트를 만드는 데 필요한 깔끔한 방법을 제공합니다. 그러나 Enterprise License를 기반으로 추가 비용이 발생하므로 값 비싼 옵션입니다. Find out more..
가장 많은 시간을 소비하는 측면은 새로운 버전의 테이블에서 외래 키 관계를 관리하는 것입니다. 합성 기본 키를 사용한다고 가정하면 아카이브 프로세스는 새 ID를 생성 한 다음 참조하는 외래 키의 새 버전에서 종속 레코드에 종속 된 키를 생성해야합니다.
이 점에 대해 생각하면 각 버전에 대한 탁월한 테이블이 매우 매력적으로 보입니다.그 보관 당신은 버전 테이블을 작성하는 동안 다운 타임을 방지 할 수 있습니다 단순히
create table customers_n as select * from customers;
의 프로세스가되도록 사용의 용이성을 위해 나는 유엔 - 접두사 현재 버전을 유지하는 것입니다. 이 경우 아카이브 전환에 이르는 동안 테이블의 상태를 캡처하기 위해 구체화 된보기를 사용할 수 있습니다. 시계가 12가되면 새로 고침을 끌 수 있습니다. (경고 : 즉석에서 생각하고 있습니다. 구매하기 전에 시도한 적이 없습니다.)
여러 테이블 (및 파티션)의 장점 중 하나는 보관 된 레코드를 읽기 전용으로 이동할 수 있다는 것입니다 테이블 스페이스. 이렇게하면 원하지 않는 변경 사항이 발생하지 않을뿐만 아니라 후속 백업에서 제외 할 수 있습니다.
편집
난 당신이 보관 된 데이터가 occasionbally 수정 될 수 있다는 댓글을 달았 알 수 있습니다. 읽기 전용 테이블 스페이스로 이동하는 것은 불가능합니다.
출처
2010-01-22 07:54:12
APC
일단 데이터가 보관되면 데이터에 액세스해야합니까? 결합 된 여러 해 데이터 세트를보고 해 주시겠습니까? –
예 데이터는 경우에 따라 액세스되고 기록됩니다. – twiga
테이블 디자인에 "YEAR"을 키로 포함시켜야하는 것 같습니다. 예를 들어 CUSTOMER 테이블과 같이 지워지지 않는 테이블이 없습니까? –