3
동일한 도메인의 클라이언트에 데이터를 제공하는 액세스 데이터베이스가있는 로컬 서버가 있습니다. 이제 우리는 외부에서 호스팅되는 웹 사이트를 가지고 있고 제품, 카테고리 및 주문 등의 업로드/다운로드 기능을 제공하는 브리지 시스템을 사용하고 있습니다.로컬 및 원격 데이터 동기화
제품, 카테고리 및 고객 등은 로컬로만 추가 할 수 있지만, 로컬 및 웹 사이트 모두에서 주문을 추가 할 수 있습니다. 우리는 웹 서비스를 사용하는 브리지 애플리케이션에 의해 이들을 동기화하려고 노력하고 있습니다. 우리는이 방법을 사용해 왔지만 더 많은 문제를 겪었습니다. 우리의 현재 접근 방식은 다음과 같습니다
- 모든 개인 기록 로컬 ID (LUID)와 웹 서버 ID (SUID) 항목이 웹 사이트에 추가 될 때, 사용의 한 예는있다, 그것은 고유 SUID가 주어집니다 luid가 -1 인 경우 브리지 응용 프로그램에서 항목을 다운로드하면 luid가 적용되고 업데이트됩니다. 이것은 로컬 서버에 추가 된 항목의 역입니다.
- 모든 개별 레코드에는 플래그 필드 (삽입, 업데이트, 제거 (웹 사이트에서 삭제) 및 삭제)가 있습니다.
위의 코드는 luid와는 별개로 suid 접근법을 사용하면 항목을 다운로드 한 후 레코드 관계를 쉽게 추적 할 수 없습니다. 이러한 접근 방식은 일방 통행 데이터 (예 : 웹 사이트에 제품을 업로드하여 동적으로 업데이트 및 제거)에 업로드하는 것만으로 효과적입니다.
이 문제를 해결하려면 항목을 양면에 추가하고 적절히 동기화 할 수있는 GUID 또는 COMBs GUID 접근 방식을 고려해 보았습니다. 성능 문제가 다소 걱정되었습니다.
몇 가지 중요한 포인트는
- 로컬 서버는 모든 것이 (결국)에 저장해야 할 데이터 "베이스 캠프"입니다.
- 로컬 브리지 응용 프로그램 만 웹 서비스로 인해 웹 서버에 요청할 수 있습니다.
- 인터넷 연결이 항상있을 수있는 기회를 지원해야하므로 웹 서버에서 고유 ID를 요청하는 것이 이상적이지 않습니다.
누구나 이런 종류의 '동기화'를 처리하는 프로그래밍 방법에 대한 의견이 있습니까?
웹 사이트를 사용할 때 웹 사이트가 이러한 GUID를 조인에 사용하기 때문에 성능에 대한 염려가있었습니다. 이것이 여전히 문제가 아니라고 생각하십니까? –
GUID 또는 현재 ID를 사용하여 비교 하시겠습니까? 키 크기가 GUID보다 크기 때문에 성능이 더 나쁩니 까? 저의 임무는 성능에 미치는 영향이 작을 것이지만, 성능 관련 모든 것과 마찬가지로 실제로 알고있는 것은 측정하는 것입니다. 사소한 성능 오버 헤드가되는 것을 피하기 위해 복잡한 디자인을하는 것은 너무나 흔한 실수입니다. – djna
로컬 및 서버 ID를 동기화 할 때 설정하지 않고 GUID에 조인을하고 별도로 연결해야합니다. GUID 및 의심되는 테이블 크기와의 관계로 몇 가지 성능 테스트를 수행 할 것입니다. 대단히 감사합니다. –