2

現在、地理的に異なる場所にあるオフィス間でデータを共有する最善の方法を見積もっています。
私の現在の好みは、SQL Server マージ レプリケーションを使用し、メイン データベースと少数のサブスクライバーを使用することです。

システムはまた、いくつかの作業現場が切断された状態で作業できるようにする必要があります (建設現場では接続がないか、ほとんど接続されていません)。

データ量はそれほど多くはありません。製造工場、少数の地域オフィス、作業現場の間でカスタム ERP システムからのデータを共有することについて話しているのです。

Sync Frameworkも見栄えがよく、SQL Server 2008 で適切にサポートされているようです。

  1. これらのニーズに応えることができる、他にどのような実績のあるシステムを調査する必要がありますか?
  2. 同様の環境でデータを共有した経験のある方のために、特に推奨事項やヒントはありますか?
  3. データの競合に対処するのはどの程度困難でしたか?
4

2 に答える 2

1

間違いなく SQL Server レプリケーションに固執し、「独自のレプリケーション フレームワークを構築する」という道をたどることを決定します。そのようにして、いくつかのアプリケーションがひどい混乱になるのを見てきました。

切断されたモデルでスナップショット レプリケーション用にセットアップされた環境がありましたが、リモート サイトは読み取り専用でした。それらは最小限の問題で非常にうまく機能しました。

また、同期フレームワークに関する人々の経験を聞くことにも興味があります。

マイクロソフトがスマート クライアントと呼んでいるものを確認することをお勧めします 。これは、マイクロソフトが一時的なネットワーク接続を持つ可能性のあるアプリケーションについて話しているアーキテクチャです。

于 2008-12-09T13:39:52.543 に答える
0

#cycnus を使用して、SQLServer2005 に関する私自身の経験については既に説明しました。私の答えは本当のものではなく、私が非常に興味を持っている主題を開始するためのいくつかの議論にすぎません.

  1. 「常に接続されているわけではない」サイトに対する私たちの選択は、Web ベースのマージ レプリケーションを実装することです。データ交換はたまたま VPN よりも高速です (LAN マージ レプリケーションも組み合わせているため)。Web (512 ダウン/128 アップ、共有) を介して毎秒 30 ～ 40 行の速度を簡単に取得し、LAN (海外、256 アップ/ダウン、専用) を介して毎秒 5 行を取得します。理由は聞かないで...
  2. Tips are numerous: subscription should be of the client type (data circulating basically from the suscriber to the publisher before being distributed). Primary Keys should allways be GUID, for many reasons exposed here, but also for replication issues: we are then sure that any newly created record will be able to find its way up to the publisher, as its PK will be unique. Moreover, I recently had a non-convergence issue with one of my replications (bad experience, exposed here) , where I felt very happy not to use natural keys, as the problem occured on the potential "natural key" column.
  3. したがって、データの競合は基本的に、作業組織の問題に限定する必要があります。この場合、(通常は悪い理由で) 同じデータが異なる場所の異なるユーザーによって同時に変更されます。私たちの「PK は GUID ルール」では、これらの特定の状況からの競合はありません。
  4. レプリケーションが実行されている場合でも、データベース構造を変更できる可能性が常にあるはずです。マージ レプリケーション プロセスの実行中に、フィールド、インデックス、制約を追加し続けることができます。また、レプリケーション プロセスを再初期化せずにテーブルを追加するための回避策も見つけました (ここで公開されていますが、この回答に反対票を投じられた理由をまだ理解していません!)
于 2008-12-09T17:31:25.713 に答える