17

SQL Enterprise を使用してすべてのデータを 4 つの異なる DB に格納するアプリがあります。ユーザーが「オフライン」で作業できる機能を組み込む必要がありました。私はこれを全員Merge Replicationのローカルインストールまで達成しました。SQL Expressこの「作品」ですが、スレッジハンマーのアプローチのように感じます。

たとえば、個々のユーザーが 100 人程度しか操作できない場合、14000 人全員をすべての DB に複製しています。それは、セントラル DB への接続の間に 5 つ以上の人と対話することは決してないという事実を数えていません。

私が探しているのは、ヒント、ポインター、そしておそらく、Sync Framework 2 (データベースを使用) に関する優れたチュートリアルです。あなたにとって何がうまくいったか、そしてその理由についての直接の説明も大歓迎です。で作業するための明確で簡潔な（現在のことは言うまでもありません）チュートリアルにまだ出くわしていませんSync Framework。

私の詳細はMS SQL Server 2005、または2008年、任意のバージョンです。任意.Netのバージョン (3.5 または 4)。現在のデータ層は allLinqToSQLです。現在使用中のものはありませんSprocs。

私の考えでは、これまでのところ、割り当てられたケースロードと関連データのみを各作業員に同期することです。理想的には、訪問する予定のメンバーを選択し、必要なデータを同期する「チェックイン/チェックアウト」形式に直接進むことができます。

おまけとして、誰かがこれが何と呼ばれているか教えてもらえますか? 私はいつも「時々接続」に出くわしますが、それは不正確なようです. それらを「時々DIS接続」と呼ぶ方が正確でしょうか？

4

9 に答える 9

3

私たちは 2 つのプロジェクト (1 つは SQL サーバー、もう 1 つは PGsql) で Sync フレームワークを使用してきたので、かなりうまく機能していると言えます。

このウォークスルー アプリケーションをチェックして、何ができるかを理解してください。

http://code.msdn.microsoft.com/sync/Release/ProjectReleases.aspx?ReleaseId=4835

これにより、複数の SQL Server データベース間でデータを同期する方法が示されます。また、'increments' ストアド プロシージャをカスタマイズして、カスタム パラメーターを取得し、これらのパラメーターに基づいてデータをフィルター処理することもできます (たとえば、クライアント ユーザーが訪問する予定の人など)。

また、奇妙なエラーが発生した場合に備えて、Sync フレームワーク コードを逆コンパイルするためにリフレクターを使用することをお勧めします。Redgateは私にとって完璧に機能します!

さらにサポートが必要な場合はお知らせください。

于 2010-08-19T11:49:01.737 に答える
1

http://code.msdn.microsoft.com/sync/Release/ProjectReleases.aspx?ReleaseId=3422 これは、SQL Server CE を使用した優れたウォークスルーであり、実行しようとしている作業に最適であり、フットプリントがはるかに小さくなります。 . 失われた機能は、あなたがやろうとしていることを少しも妨げないように思えます。

于 2010-08-20T12:36:55.697 に答える
1

明白/役立つかもしれないし、そうでないかもしれないいくつかの提案とヒントがあります.

私には、これは 3 つの別々の側面に分割できる問題のように思えます。

同期プロセス

  • すべての行にある種の「last_update」列があることを確実にする必要があります。これにより、同期プロセスが効率的かつ確実にどのデータが既に最新であるかを判断できるようになります。あなたは同期しています。
  • 複雑な同期プロセスを避け、可能な限り力ずくのアプローチを使用します。14,000 レコードというのは、私にはそれほど多くないように思えます。最適化を行うことで、接続間で行われたすべての変更を適切な時間内に同期できることがわかるかもしれません。そうでない場合でも、ユーザーが気付かずに古いデータで作業することを避けるために、同期するものについてはかなり寛大になるでしょう。

オフライン モードで行われた変更のプッシュ

可能であれば、オフライン モードでの変更を単に禁止するだけです。それが不可能な場合は、変更のプッシュを別の (そしておそらくかなり複雑な) プロセスとして検討する必要があります。

アプリケーションについて詳しく知らなければ、同期プロセスはビジネスに大きく依存するため、適切な提案を行うことは困難ですが、考慮すべき点がいくつかあります。

  • ユーザーがアイテムをロック (またはチェックアウト) して、他のユーザーがオフラインで作業しているときにアイテムを変更できないようにする必要がありますか?
  • ロックをオーバーライド可能にする必要がありますか?
  • ロックがオーバーライドされた場合、誰かが変更を保存しようとするとどうなるか (マージ プロセスは賢明な選択のようです)
  • チェックアウトしていないアイテムを誰かが編集できるようにする必要がありますか?

複雑なオフライン変更プロセスを実装することに決めた場合は、一般的な分散型 VCS で使用されるワークフローを参考にしてください。

オフライン データ ストアの変更

ローカル データ ストアとしてSQL CompactまたはSQLiteを使用する方がより洗練されたソリューションであることに気付くかもしれません(確実にインストール プロセスが簡単になります)。 SQL サポート。

この変更は、エンド ユーザーの改善点が最も少なく、おそらく最も手間がかかるため、最初に上記の 2 つに焦点を当てます。上記の 2 つは、SQL Server Express をローカル データ ストアとして使用している場合でも完全に達成できます。

于 2010-08-16T06:28:23.630 に答える
0

MicrosoftSyncがあなたにとって良い選択肢かもしれないように私には聞こえます。データベースの同期の概要については、http：//msdn.microsoft.com/en-us/sync/bb887608.aspxを参照してください。それを見て、それがあなたのニーズを満たしているかどうかを確認してください。それはあなたの問題に対する完璧な解決策のように聞こえます。

于 2010-08-11T16:03:48.920 に答える
0

同期フレームワークと何日も苦労した後、私はそれを捨てて、いくつかの単純なWCFサービスとコードを書くことを考えています。私の要件は、モバイルデバイス上のSQL2008からSQLCEへの一方向の同期です。私の経験から、カスタマイズすることは非常に難しく（一部のフィールドのみを同期するなど）、非常に遅く非効率的です。Microsoftは、もう少し使いやすくするために、もう少し作業を行う必要があると思います。

乾杯

マーク

于 2010-08-19T00:08:29.620 に答える
0

This is essentially called Distributed Computing.

In any such system that I've worked on, I've typically used a N-Tier Architecture to allow for occasional connecting of a client program to the database server on the back-end for CRUD operations. Any work that the client does is considered connection-less, as they do not interact with the server until they save their changes.

Using this kind of approach you should be able to make an application that allows them to connect for a moment to get some data, perform some work on the data and then propagate any changes (CRUD) to the server (database).

I would have to say that using Merge replication with Local Sql Express installs is for sure a sledge hammer approach. Don't feel too bad about it, we all do it from time to time :P.

EDIT

I have not used Sync Framework myself, but it seems nice. Check out the Sync Framework Developer Center for some more information on it.

于 2010-08-11T15:57:56.790 に答える
0

マージ レプリケーション アーティクルを行レベルでフィルタリングしようとしましたか? これにより、14k 行のサイズが管理しやすいサイズに縮小されます。

于 2010-08-19T14:54:42.343 に答える
0

データの結合オプションをより細かく制御する必要があるようです。この要件により、2 種類のデータがあることがわかります。メンバーに属するデータ（ケースはメンバーに属します）、および共有データ（リファレンス、マスター データ）。

この場合、物事を半速にするためにこれらの手法を組み合わせます。

たとえば、マスター データと参照データの変更はそれほど頻繁ではありません。したがって、頻繁に同期する必要はありませんが、変更を制御する必要があり、中央の場所で行う必要があります。この場合、セントラル DB で変更を行い、スレッジ ハンマー アプローチを使用します。

トランザクション データの場合、一方向性を想定すると、この場合、メンバーは自分に属するケース/行のみを変更でき、多くの方法を使用して実装できます。

前述のように、Sync Framework Developer Center または ActiveSync を使用できます。

PDA や Palmtops のようにしきい値がそれほど厳密ではないため、ラップトップを使用しているため、手動のアプローチも試すことができます。作成、更新、および削除されたデータに接続してプッシュする機能/プロセス ルーチンを実装する (この場合、データベース レベルでフラグを維持する必要があります)。このシナリオで最も一般的なアプローチである BulkCopy 操作を使用します (ボタンを提供する必要があります)。メンバーがクリックして呼び出すか、接続をポーリングしてチェックし、同期ルーチンを自動的に開始するサービス)。

/KP

于 2010-08-15T16:00:38.873 に答える
0

問題は、ローカルに保存された切断されたデータを使用してアプリをデバイス上で実行する必要があるか、またはデータを操作するときに常にサーバーに接続する必要があると想定されているため、Web フロント エンドのモバイル バージョンを作成できるかということです。 ?

私が (ずっと前に) 取り組んだプロジェクトでは、コンパクトなフレームワークとアクティブシンクを Access または SQL Server バックエンドのいずれかで使用していました。電話のように各デバイスを常時接続するには費用がかかりすぎたためです。彼らはデバイスを現場に持ち込み、切断されたデータベースからデータにアクセスする必要があり、モッドを行い、オフィスに戻ったときに同期しました.

そのような場合は、deviceID を使用して各デバイスに必要なケース/行を特定できますが、カスタム同期ソリューションの開発を考えている場合は、間違った戦いをしていると思います. それはすでに行われています。実績のある同期ソリューション、制限などを使用し、同期データを制限するために使用できる基準に焦点を当てます。

于 2010-08-12T17:38:56.963 に答える