Duy trì tính toàn vẹn tham chiếu giữa máy khách di động và máy chủ

Vì vậy, tôi có một hệ thống tương đối đơn giản. Một máy khách di động tạo các bản ghi trong cơ sở dữ liệu sqlite mà tôi muốn được đồng bộ hóa với máy chủ SQL từ xa (được chia sẻ với các máy khách di động khác) . Vì vậy, khi tôi tạo một bản ghi mới trong bảng sqlite của điện thoại, sau đó tôi sẽ đẩy thay đổi đó sang dịch vụ từ xa của mình thông qua API RESTful. Vấn đề tôi gặp phải là làm cách nào để đặt các khóa chính sao cho không xảy ra xung đột trong dữ liệu (tức là một bản ghi trong điện thoại có cùng khóa chính với một bản ghi hoàn toàn khác trên máy chủ). "Cách thực hành tốt nhất để tham chiếu bản ghi trên máy khách là gì và để tham chiếu cùng một bản ghi trên máy chủ?

Cách làm thông thường là cấu trúc cơ sở dữ liệu của bạn bằng uniqueidentifiercác khóa (đôi khi được gọi là UUID hoặc GUID). Bạn có thể tạo chúng ở hai nơi mà không sợ va chạm thực tế.

Tiếp theo, ứng dụng Di động của bạn cần đồng bộ hóa các bảng "thực tế" từ máy chủ trước khi bạn có thể tạo các hàng mới. Khi bạn tạo các hàng mới, bạn thực hiện cục bộ và khi bạn đồng bộ lại, các hàng mới sẽ được thêm vào máy chủ. Bạn có thể làm điều tương tự với các bản cập nhật và xóa quá.

Để theo dõi các phần chèn, bạn cần có dấu thời gian đã tạo trên các hàng của mình. Để theo dõi các cập nhật, bạn cần theo dõi dấu thời gian LastUpdate trên các hàng của mình. Để theo dõi xóa bạn cần một bảng bia mộ.

Lưu ý rằng khi bạn thực hiện đồng bộ hóa, bạn cần kiểm tra thời gian bù giữa máy chủ và thiết bị di động và bạn cần có phương pháp để giải quyết xung đột. Chèn không phải là vấn đề lớn (chúng không nên xung đột), nhưng các bản cập nhật có thể xung đột và việc xóa có thể xung đột với bản cập nhật.

Có các khung để xử lý loại việc này, chẳng hạn như Microsoft Sync Framework .

Tôi cá rằng bạn hoàn toàn, không có câu hỏi có thể có tính toàn vẹn tham chiếu giữa hai. Cụ thể, người dùng của bạn có mong đợi ứng dụng di động hoạt động khi bị ngắt kết nối không?

Có hai thực hành cho việc này:

Một là tạo các bản ghi "tạm thời" trên máy khách, và sau đó khi bạn đồng bộ hóa chúng với máy chủ, hệ thống trung tâm sẽ gán ID. Khách hàng có thể cập nhật hồ sơ địa phương để phản ánh điều đó.

Mặt khác là bạn phân phối việc tạo ID theo cách (thông thường là xác suất) cho phép khách hàng tạo ID mà không bị va chạm.

Vì thế, đi đến UUID - v4 khá khó xảy ra va chạm.

Mặt khác, hãy xem xét một cái gì đó đặt ID thiết bị di động duy nhất trong ID hồ sơ. Vì vậy, ID hồ sơ của bạn có thể là ${imei}-${local sequence number}một cái gì đó, trong đó IMEI đảm bảo tính duy nhất và số thứ tự cục bộ chỉ là một ID cơ sở dữ liệu tuần tự bình thường.

Ngoài câu trả lời của Daniel Pittman , một khả năng là máy chủ sẽ gán cho mỗi khách hàng một ID khách hàng duy nhất và biến ID khách hàng thành một phần của khóa chính.

Tôi có cùng một vấn đề với một dự án tôi đang thực hiện, giải pháp trong trường hợp của tôi là tạo ra một trường nullable bổ sung trong các bảng cục bộ có tên remote_id. Khi đồng bộ hóa các bản ghi từ cơ sở dữ liệu từ xa sang cơ sở dữ liệu từ xa nếu remote_id là null, điều đó có nghĩa là hàng này chưa bao giờ được đồng bộ hóa và cần trả về một id duy nhất khớp với id hàng từ xa.

Local Table            Remote Table

_id (used locally)
remote_id ------------- id
name      ------------- name

Trong ứng dụng khách tôi liên kết các bảng theo trường _id, từ xa tôi sử dụng trường id từ xa để tìm nạp dữ liệu, tham gia, v.v.

ví dụ tại địa phương:

Local Client Table       Local ClientType Table      Local ClientType
                         _id
                         remote_id  
_id -------------------- client_id
remote_id                client_type_id -------------- _id
                                                      remote_id
name                    name                          name

ví dụ từ xa:

Remote Client Table      Remote ClientType Table      Remote ClientType
id -------------------- client_id
                        client_type_id -------------- id
name                    name                          name

Kịch bản này và không có bất kỳ logic nào trong mã sẽ gây ra lỗi toàn vẹn dữ liệu, vì bảng client_type có thể không khớp với id thực trong bảng cục bộ hoặc từ xa, bất cứ khi nào remote_id được tạo, nó sẽ trả về tín hiệu cho ứng dụng khách yêu cầu cập nhật trường _id cục bộ, điều này kích hoạt trình kích hoạt được tạo trước đó trong sqlite cập nhật các bảng bị ảnh hưởng. http://www.sqlite.org/lang_createtrigger.html

1- remote_id được tạo trong máy chủ

2- trả lại tín hiệu cho khách hàng

3- khách hàng cập nhật trường _id của nó và kích hoạt trình kích hoạt cập nhật các bảng cục bộ tham gia local _id

Tất nhiên tôi cũng sử dụng một trường last_updated để giúp đồng bộ hóa và để tránh các đồng bộ trùng lặp.