5

同期フレームワークはテーブルごとにデータを同期しますが、エンティティは関連する親子テーブルのセット間で正規化されます。これにより、処理対象のサーバー上に親行が表示される可能性がありますが、子行が数秒間表示されないというアプリケーションの問題が発生します。クライアント アプリとサーバー間の接続に問題がある場合、子行がしばらく表示されないことがあります。

親テーブルとは別に同期される子テーブルを処理するようにアプリケーションを設計するにはどうすればよいですか?

私が検討している具体的なシナリオは、バックエンド システムからサーバーで作業指示書を受け取り、タブレット PC または PDA を使用して現場のエンジニアに配布することです。これらの作業指示書は、半ダースのテーブルをカバーする可能性がある大規模で複雑なエンティティです。エンジニアが作業を完了し、結果を同期すると、サーバーは完了した作業指示書をバックエンド システムに返します。

これまでの私自身のアイデアのいくつかを以下に掲載します。

4

6 に答える 6

2

同期フレームワークを使用して、関連するテーブルを独自の同期グループに追加します。たとえば、OrderHeader テーブルと OrderDetail テーブルを Orders という独自の同期グループに追加します。

直接関連しない限り、同期グループには何も入れないでください。

次に、トランザクション内の各同期グループを同期します。そうすれば、両方のテーブルを同期するか、まったく同期しないことが保証されます...

このプロセスの詳細が必要な場合はお問い合わせください。

于 2010-02-21T20:55:31.987 に答える
0

Sync Frameworkをカスタマイズして、データベースの関係を尊重するようにすることができます。カスタムSyncAdapterが変更のある行に遭遇すると、データベーススキーマの子関係をトラバースして、関連する行の変更を取得する可能性があります。これらの変更はすべて同じデータセットに追加され、単一のトランザクションとして同期されます。

長所：

  • これは、データの整合性の観点からは最善の解決策のようです。特定のエンティティに、クライアントから利用可能なすべての変更が含まれているか、含まれていないことを確認できます。
  • エンティティを変更したり、カスタムアダプタに特別な方法で記述したりする必要はありません。必要なすべての情報は、すでに持っているデータベース関係から取得できます。
  • データベーススキーマで特別なことをする必要はありません。コードを任意のデータベースに向けることができ、それで問題なく動作します。

短所：

  • この方法で同期フレームワークをカスタマイズするのは大変な作業になる可能性があり、フレームワークの内部に関する詳細な知識が必要になります。
  • カスタムアダプタは、循環データベース関係を検出して処理する必要があります。
于 2010-02-18T14:59:23.337 に答える
0

データが異なる時間に表示されるかどうかが問題にならないようにアプリケーションを設計します。アプリは、その時点で利用可能なデータを表示または操作します。後でさらにデータが表示される場合は、それも表示されます。

長所：

  • これは、データを処理するための柔軟で堅牢な方法であり、多くの複雑な同期コードに依存しません。

短所：

  • ユーザーが完全なタスクや作業指示書などを見ていると思った場合、ユーザーを混乱させる可能性がありますが、後で余分な部分が表示されます。
  • データがユーザーからサーバーに同期されて他のバックエンドシステムに送信される場合、そのシステムは部分的な送信をサポートしていない可能性があります。
于 2010-02-18T15:09:11.583 に答える
0

私の考えのためのコメント ボックス内に十分なスペースがありません :

リレーショナル データの代わりにマスター エンティティを同期しますか? 同期フレームワークでそれができるかどうかわかりません...カスタムプロバイダーを実装するかもしれませんか?

トランザクションに関してはまだ問題があります。ばかげたサンプルを見てみましょう。アカウントがあり、各アカウントはマスター エンティティです。

データベース A

BeginTransaction
    Substract $500 from account 1
    Add $200 to account 2
    Add $300 to account 3
EndTransaction

データベース B

BeginTransaction
    Substract $100 from account 1
    Add $100 to account 4
EndTransaction

同期すると、1 で競合が検出されますが、2、3、および 4 では競合が検出されません。このサンプルを使用すると、マージ戦略を詳しく説明できますが、常にそうとは限りません。

于 2013-02-22T15:20:39.477 に答える
0

すべてを非正規化します。関連するテーブルを 1 つの結合された結果セットにフラット化するデータベース ビューを作成するか、最初から 1 つの大きなテーブルにデータを格納します。その 1 つのテーブルを同期するように Sync Framework を構成し、ビューの「一番左」のキー (階層内のルート テーブルの主キーである必要があります) でバッチ処理します。クライアント上の各トランザクションは、単一のエンティティに対して行われたすべての変更で構成されます。

長所：

  • データベースに完全に実装できます。
  • Sync Framework のどの部分も置き換える必要はありません。
  • ビューがどのように構築されてフィルター処理されたか、および基になるテーブルがどのようにインデックス付けされたかに注意を払っている限り、多数の行にかなりうまくスケーリングする可能性があります。

短所：

  • データベースの正規化を放棄することは、悪いと見なされる可能性があります。
  • 多くの結合が必要なため、多数のテーブルと列にうまくスケーリングできない可能性があります。
  • 変更追跡データも集約する必要があります。
  • ビューを使用している場合は、トリガーを作成して更新可能にする必要があります。
于 2010-03-03T18:56:03.580 に答える
0

チェックサムのあるものはどうですか？アプリケーションは、エンティティに変更を加えるたびに、エンティティの最新の内容に基づいてハッシュを計算し、それを親行に保存します。アプリケーションがエンティティを読み取ると、ハッシュを再計算できます。その時点で利用可能なデータが、エンティティに格納されているハッシュと一致しない場合、アプリケーションは、さらに同期を行う必要があることを認識します。

長所：

  • Sync Framework の内部の変更を伴わない、アプリケーションのドメイン モデルに対するかなり単純な変更である可能性があります。

短所：

  • アプリケーションは、変更を加えるたびに、エンティティに関連するすべての行をメモリに読み込む必要があります。
  • アプリケーションが複数のクライアントからの同じエンティティへの更新をサポートする必要がある場合、これはさらに複雑になります。
  • 各方向で同期される変更と、対応するハッシュがいつ計算されるかを慎重に計画する必要があります。データによっては、同じテーブルを数回同期する必要がある場合があります。
  • 1 つのアプリケーションに合わせてオーダーメイド。同じコードを別のものに適用することはできません。
于 2010-02-18T15:22:38.530 に答える