두 개의 다른 데이터베이스가 있습니다. 그 중 하나는 원본 데이터베이스이고 다른 하나는 캐시 데이터베이스입니다.웹 서비스를 통해 다른 위치에있는 다른 동일한 테이블의 테이블을 업데이트하십시오.
이 데이터베이스는 다른 위치에 있습니다. 하루 만에 캐시 데이터베이스를 원본 데이터베이스에서 업데이트해야합니다. 그리고 원본 데이터베이스 시스템에서 작동하는 웹 서비스를 업데이트해야합니다.
모든 진행 상황에서 모든 캐시 DB 테이블 및 원본 데이터 삽입을 취소하면됩니다. 하지만 나쁜 시나리오라고 생각합니다. 이 업데이트를 어떻게 효율적으로 진행할 수 있습니까? 그리고 어떤 제안이 있어도.
나는 이미 DB 동기화 기술이 있다고 확신하지만 이미 요구 사항이 있으므로 변경 로그를 사용하는 것이 좋습니다.
그래서 테이블에 "쓰기"(INSERT, UPDATE, DELETE) 할 때마다 행을 삽입하는 "CHANGE_LOG"테이블이 있습니다. 하루에 한 번씩 이러한 변경 사항을 캐시 DB에 하나씩 적용 할 수 있습니다.
적용한 후에 변경 로그를 삭제해도 괜찮지 만 DB에 "버전"을 부여 할 수도 있습니다. 따라서 DB를 변경할 때마다 버전 번호가 증가합니다. 이것은 하나 이상의 chache DB를 관리하는 데 사용될 수 있습니다.
예를 들어 추가 보증을 제공하기 위해 캐시 DB에 트리거를 추가하여 버전 번호를 증가시킬 수 있습니다. 그렇게하면 프로세스가 캐쉬 DB를 조회 할 수 있고 변경 사항을 적용해야 하는지를 마스터 DB에서 유지하지 않고 알 수 있습니다. (그런 식으로 새 캐쉬 DB를 연결하여 최신 캐쉬 DB를 최신 상태로 유지하는 것은 쉽습니다.).
때때로 변경 로그를 제거해야 할 수도 있습니다.
원본 데이터베이스에서 모든 데이터를 가져와야합니다. 어떤 데이터가 변경되었는지 확인하기 위해 조사 할 방법이없는 것처럼 보입니다. 이를 수행하는 간단한 방법은 소스 데이터베이스의 모든 데이터를 캐시 데이터베이스의 임시 또는 스테이징 테이블로 복사하는 것입니다. 그런 다음 두 테이블 세트간에 diff를 수행하고 변경된 레코드를 업데이트 할 수 있습니다. 또는 일단 스테이징 테이블의 모든 데이터를 h 제하거나 기존 테이블의 이름을 바 Y 고 스테이징 테이블의 이름을 기존 테이블 이름으로 변경하십시오.
감사합니다. Zwei, 원본 (원본) 데이터베이스가 아닙니다. 그래서 나는 소스 데이터베이스에서 anythink를 할 수 없다. 웹 서비스 및 대상 컴퓨터에서 everythink해야합니다. – Murat
원본 데이터베이스를 제어 할 수없는 경우 diff를 수행해야합니다. 그렇지 않으면 삭제 및 업데이트 (기본 키를 가상 버전 정보로 사용하여 삽입을 감지 할 수 없기 때문에)를 수행 할 수 없기 때문입니다. 그리고 diffs 비싸다. 그래서 내가 너라면 내가 경영진과 얘기 할거야. –