モバイルクライアントとサーバー間の参照整合性の維持

だから私は比較的単純なシステムを持っています。モバイルクライアントは、私が（他のモバイルクライアントと共有されている）は、リモートSQLサーバーに同期しているしたいとSQLiteのデータベースのレコードを作成します。そのため、電話のsqliteテーブルに新しいレコードを作成するとき、その変更をRESTful APIを介してリモートサービスにプッシュします。私が抱えている問題は、データの衝突がないようにプライマリキーをどのように注文するかです（つまり、電話のレコードはサーバー上の完全に異なるレコードと同じプライマリキーを持っています）。クライアント上のレコードを参照し、サーバー上の同じレコードを参照するための通常の「ベストプラクティスは何ですか？」

通常は、uniqueidentifierキー（UUIDまたはGUIDと呼ばれることもあります）を使用してデータベースを構築します。衝突を現実的に恐れることなく、2つの場所で作成できます。

次に、新しい行を作成する前に、モバイルアプリでサーバーの「ファクト」テーブルを同期する必要があります。新しい行を作成すると、ローカルで作成され、再度同期すると、新しい行がサーバーに追加されます。更新と削除でも同じことができます。

挿入を追跡するには、行に作成されたタイムスタンプが必要です。更新を追跡するには、行のLastUpdateタイムスタンプを追跡する必要があります。削除を追跡するには、トゥームストーンテーブルが必要です。

同期を行うときは、サーバーとモバイルデバイス間の時間オフセットを確認する必要があり、競合を解決する方法が必要であることに注意してください。挿入は大したことではありません（競合するべきではありません）が、更新は競合する可能性があり、削除は更新と競合する可能性があります。

Microsoft Sync Frameworkなど、この種のことを処理するフレームワークがあります。

間違いなく、2つの間に参照整合性を持たせることはできません。具体的には、ユーザーはモバイルアプリケーションが切断されたときに動作することを期待していますか？

これには2つのプラクティスがあります。

1つは、クライアント上で「仮」レコードを作成し、それらをサーバーに同期するときに、中央システムにIDを割り当てさせることです。クライアントは、ローカルレコードを更新してそれを反映できます。

もう1つは、クライアントが衝突することなくIDを作成できるように（通常は確率的に）ID作成を配布することです。

そのためには、UUIDにアクセスしてください-v4は衝突する可能性がかなり低いです。

そうでない場合は、一意のモバイルデバイスIDをレコードIDに入れるものを検討してください。したがって、レコードIDは${imei}-${local sequence number}、IMEIが一意性を保証し、ローカルシーケンス番号が通常の連続したデータベースIDであるようなものかもしれません。

Daniel Pittmanの答えに加えて、サーバーが各クライアントに一意のクライアントIDを割り当て、クライアントIDを主キーの一部にする可能性があります。

私が取り組んでいるプロジェクトでも同じ問題があります。私の場合の解決策は、remote_idという名前のローカルテーブルに追加のnull許容フィールドを作成することでした。remote_idがnullの場合、ローカルデータベースからリモートデータベースにレコードを同期する場合、この行は一度も同期されておらず、リモート行IDと一致する一意のIDを返す必要があることを意味します。

Local Table            Remote Table

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

クライアントアプリケーションでは、テーブルを_idフィールドでリンクし、リモートでリモートIDフィールドを使用してデータを取得したり、結合したりします。

ローカルの例：

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

リモートの例：

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

client_typeテーブルはローカルテーブルまたはリモートテーブルの実際のIDと一致しない可能性があるため、このシナリオは、コードに論理的なものがないと、データ整合性エラーを引き起こします。したがって、remote_idが生成されるたびに、クライアントアプリケーションに信号を返しますローカル_idフィールドの更新を要求すると、これは、影響を受けるテーブルを更新するsqliteで以前に作成されたトリガーを起動します。 http://www.sqlite.org/lang_createtrigger.html

1-remote_idはサーバーで生成されます

2-クライアントにシグナルを返します

3-クライアントは_idフィールドを更新し、ローカル_idに参加するローカルテーブルを更新するトリガーを起動します

もちろん、同期を支援し、同期の重複を避けるために、last_updatedフィールドも使用します。