2

サーバーからのデータを利用するアプリケーションを構築したいと考えており、アプリケーション内のデータを他のクライアント アプリケーションによって入力されたデータと同期する必要があります。それで、いくつかの質問があります:

  • データベーススキーマを効率的に設計するには? サーバー上で同じデータベース スキーマを複製する必要がありますか、それともフィールドとエンティティをさらに追加する必要がありますか?
  • 各アプリケーションの起動時、またはアプリケーションのアイドル状態の間、またはその他の何かで、データを同期するための戦略は何ですか...
  • ユーザーがアプリケーション内で入力したデータと、別のクライアント アプリケーションによって入力されたデータの競合を処理する方法。

どんな反応でも大歓迎です。

4

1 に答える 1

5

さて、元の質問で主な課題を特定しました。本当の答えは、これは iPhone とはほとんど関係がないということです。データベースの複製は非常に困難です。

ここに私が提供できるいくつかの経験則があります:

  • データの一方向の複製は、それを回避できれば、双方向の複製よりも100 万倍簡単です。

  • データベーススキーマがクライアントとサーバーで同一であれば、レプリケーションは常に簡単です。

  • 双方向のレプリケーションを行うには、各行のタイムスタンプを両端に格納するか、一方の端の完全な内容をもう一方の端に格納する必要があります。(つまり、サーバーがクライアントの最新のステータスを知る必要があるか、クライアントがサーバーの最新のステータスを知る必要があります)。

  • 切断されたクライアントから行を追加できるようにするには、自動インクリメント フィールドではなく、 GUID (または SHA-1 などのハッシュ) を使用して行を識別する必要があります。サーバーと同期するまで、クライアントが追加した新しい行を「識別子なし」のままにしておくことは可能ですが、その方法は狂気です。

  • 競合を解決するための実際の良い方法はありません。 不完全なオプションには、last-writer-wins (変更されたレコードを最後に同期した人が挿入されたレコードのコピーを取得する)、three-way-merge (誰かが変更されたレコードを送信したときに、変更された列を確認し、それらのみを変更する) が含まれます。列、したがって他の列への変更を上書きしない)、2 つのレコードへの分割 (2 人のユーザーが同じレコードに変更を加えた場合、2 つのレコードを作成し、最終的に誰かがそれを修正すると想定する)、および「ユーザーに尋ねる」(これは技術的には最も健全ですが、多くの UI 作業が必要であり、ユーザーは競合が何であるかさえほとんど理解していません)

于 2010-03-31T18:14:34.587 に答える