オフラインモバイルアプリの同期に最適な実装は何ですか？
AndroidアプリはCordova AngularJS SPAとして記述されており、現在成長しているため、いくつかの作業を追加する必要があります。つまり、アプリの同期部分を改善する必要があります。アプリは主にオフラインで使用します。ビジネスの使用方法の詳細を説明することはできませんが、データ構造と制約は、単純化された自動車整備士のビジネスで説明できます！
データエンティティが次のようになっているとします。 
クレームは会社、ガレージ、車のレベルにあるため、ジャックは会社Aのすべての車庫とすべての車を見ることができ、ジルは会社Aのすべての車庫を見ることができ、各車庫の一部の車だけを見ることができます。 1つのガレージとそのガレージ内の一部の車のみを表示できます。 -あなたはアイデアを得ます。
- アプリは、整備士が自分の仕事について見ることができる情報をダウンロードします。彼らは、自分に割り当てられているすべてのジョブと、自分が持っているクレームが表示を許可している他のジョブを表示できるため、それらのジョブをピックアップできます。ジョブは、車で完了する必要のあるチェックポイントのグループです。
- ガレージワークショップにはデータ接続がありません。整備士が同期できるのは、オフィスに戻ったときのみです。これはユーザーが開始する必要があるかもしれませんが、まだ完全には確定していません。
- 同じデータアイテムが両方のメカニックによって更新された場合、同期された最後のアイテムが優先されます。
- 整備士がタブレットアプリにデータアイテムをダウンロードしてからサーバーでデータアイテムが更新されている場合、データアイテムを更新してアップロードすると、整備士の変更が適用されます。
- ジョブは、同期時に部分的にしか完了しない場合があります。
- アプリが同期するとき、アプリは保持している変更を適用し、SQLデータベースからの最新の情報でローカルに保持されているデータを更新する必要があります。現在または将来処理されるジョブに関係のなくなったデータをアプリから削除する必要がある場合があります。
バックエンドはAzureでホストされ、データはAzure SQLデータベースに格納されます。段階的に廃止するOData APIと、使用/追加できるWeb APIがあります。複雑な認証はAPIの共有モジュール内で行われ、アプリに取り込まれるデータは、ユーザーが見ることを許可されているデータのみです。
データは時間の経過とともにかなり大きくなります。
これはトランザクションである必要があります–つまり。同期に問題がある場合は、エンティティタイプではなく、ジョブ全体を一度に同期する必要があります。
アプリはSPA Cordovaアプリケーションとして作成されているため、やむを得ない理由がない限り、この方法を維持する必要があります。
これまでに検討したアイデア：
BreezeJSは変更の追跡に使用されています。これらの変更だけをサーバーに送信し、サーバー上のプロセスがそれらの変更をデータベースに適用するのを待ってから、必要な変更と新しいデータのダウンロードを開始できます。ただし、これは、多くの人が同時に同期していて、何かが何らかのキューに詰まっている場合、同期が完了するまでに長い時間がかかることを意味します。
CouchDb/PouchDBの使用-これについてはほとんど知りませんが、これは私たちが持っている認証モデルで動作しますか？また、マスターSQLデータベースとの間の変更を取得するにはどうすればよいでしょうか。
Azureオフラインデータ同期（ https://docs.Microsoft.com/en-us/Azure/app-service-mobile/app-service-mobile-offline-data-sync ）-限りこれはCouchDbを使用するのとかなり似ていることがわかりますか、それとも誤解していますか？
必要な承認モデルは、実行可能ないくつかのソリューションの阻害要因であると思われる部分です。特定の時点で、さまざまなユーザーがさまざまな共通データのセットを持っている必要があります。これは必須です。
マスターSQLデータベースと同期する場合、常に同じ問題が発生します。競合する変更をどのように解決しますか？
CouchDBはそこでは役に立ちません。明示的に競合を処理せず、ユーザーが（サイドを選択することにより）競合を処理するようにします。競合を解決するには、競合状態にあるデータの意味を理解する必要があるため、他のソリューションも実際には役立ちません。つまり、この問題に対する一般的な「完全な」解決策はありません。
私のアドバイスは、あなたが説明したキュー戦略へのアップロードの変更を使用して、自分でいくつかのソリューションを開発することです。パフォーマンスはおそらく最大の問題ではありませんが、競合の解決が重要になります。そのキューを処理するためのいくつかの戦略の1つを選択します。
- 楽観的同時実行制御
クライアントがシステムからデータを取り出したときのタイムスタンプを追跡し、そのデータの新しいバージョンをアップロードするときに、変更が発生していないことを確認します。変更が発生した場合は、戦略3を使用するか、ユーザーが強制または破棄できるようにします。
- ロック
ユーザーが「チェックアウト」および「チェックイン」操作を明示的に実行できるようにします。考慮すべきいくつかの基本的な事柄：他のユーザーは誰がロックを持っているかを確認し、そのロックを解除する必要があります。ロックを持つユーザーのみが、そのロックの下で保持されているデータに対して実行された変更をチェックインできます。 Subversion（およびtortoisesvnのようなクライアント）がどのようにロックを処理するかを見てください。そのようなことに関しては、それは正気です。
- マージ
これは、競合を検出したときにマージを実行することを除いて、戦略1のバリエーションです。複数の戦略を使用してこれを実装できます。最後の1つが勝ち、最初の1つが勝ち、明示的なユーザーの選択（おそらく、それらにデルタを示す）。より詳細なレベル（フォームごとではなくフィールドごと）でデータを追跡することにより、競合のリスクを減らすことができます。
目の前には細かいところはありませんが...
Azureを使用すると、モバイルアプリサービスをバックエンドとして組み合わせて、マルチユーザーの性質を処理できます。そして、私が正しく覚えていれば、それに接続されているSQLデータインスタンスを実際のデータベースに使用できます。
どちらにしても、アプリのマルチユーザーの性質を調整するには、何らかのWebサービスバックエンドが必要になると思います。私はその要件を回避する良い方法はないと思います。
@Joeri Sebrechtsが述べたように、他の方法では基本的に、ユーザーがデータをチェックインおよびチェックアウトし、責任を負うが必要です。ある日、私は開発者がそうすることをほとんど信じません。