私が取り組んできたアプリケーションの基本的なアイデアは、ユーザーのグループがフラッシュ カードの「スタック」で共同作業できるようにすることです。最終的に、アプリはクライアント サーバー システムとして機能します (iOS アプリがクライアント、Rails アプリがサーバー)。
この設計の要件は、私が見ているように、次のようなものです。
- 編集のマージをスムーズに処理する必要があります。多くのユーザーが各スタックを編集し、すべてのクライアントが変更を完了してもすぐにアップロードできない可能性があるため、設計では、共有データへの不一致な変更をエレガントに調整できる必要があります。
- 効率的である必要があります。多くのユーザーがセルラー接続を介してアプリにアクセスするため、サーバーからアップロードおよびダウンロードされるデータの量を最小限に抑え、アプリがこれらの接続で高速に実行されるようにし、すでに制限されているクライアントのデータ使用量を削減する必要があります。
当初、私は単純なルートをたどり、同期のたびにクライアントに「一括」レポートをサーバーに送信させるつもりでした。つまり、各スタックのローカル コピー全体がアップロードされ、サーバーがこれらすべてを処理するということでした。新しいデータセット全体をクライアントに送信する前に、それを以前のクライアントの編集を含む独自のマスターコピーにマージし、オフラインで表示および編集するためにこの正確なコピーを保存します。
私の設計要件を念頭に置いて、これで私が見た問題は、主にそれが恐ろしく非効率的であるということです。クライアント アプリは、このすべてのデータのアップロードとダウンロードに時間を浪費する必要があるだけでなく、ほとんどの情報が以前のコピーと同じであっても、すべての新しい情報をローカル データ ストアに書き込む必要があります。また、サーバーが効率的かつ論理的な方法で競合する編集をどのように理解するかを理解することもできませんでした。
だからここに私が思いついたものがあります：
クライアントが共有スタックに変更を加えるたびに、データベースの独自のコピーを変更するだけでなく、何が、いつ、誰によって、どのように変更されたかなど、ログに変更が記録されます。次にクライアントがサーバーと同期するとき、1 秒後または数日後に、ローカル データ コピー全体ではなく、このアクションの「受信」がサーバーに送信されます。
そこでは、サーバーは、データのサーバー コピーですべての変更を実行する前に、後世のためにこれらのアクションを最初に保存します。次に、このレシートのデータベースを使用して、クライアントが最後にデータベースと同期してからスタックに加えられた関連するすべての変更を取得します。これらのみがクライアントに送り返され、独自のローカル コピーで変更が実行されます。
クライアントが行ったすべての変更のこのログを使用して、サーバーはどの変更が他のどの変更を無効にするかを判断できます (たとえば、ユーザーがカードを削除し、この変更と同期する前に、別のユーザーが正常なカードを編集すると、削除は無効になります）。実装は複雑ですが、理論的には、これはマージの問題に対する理想的なソリューションです。
それで、あなたはどう思いますか？
これは実行可能な解決策ですか？私のマスタープランに明らかな穴がありますか？
ありがとう！