会計/在庫アプリケーションを実行する既存の SQL Server 2005 データベースがあります。独自のデータベースを持つ新しいオンライン注文フレームワークの使用を検討しています。
この新しいフレームワークを使用する場合、オンライン注文データ (在庫、価格、注文、顧客) をほぼリアルタイムで、既存の在庫データベースとの間で転送する必要があります。データの転送はリアルタイムである必要はありませんが、高速である必要があります。両方のデータベースが SQL Server になります。
だから私の質問は...異なるスキーマを持つ2つのデータベース間でデータをやり取りする最良の方法は何ですか?
複製？SSIS？あなたは何を提案しますか、そしてその理由は何ですか?
どんな助けでも大歓迎です！
ビジネスルールは難しい部分です
一方向同期？双方向同期？リアルタイムプッシュ？毎晩更新？ダンプしてリロードしますか? 比較して更新しますか？紛争解決？どちらの側が勝ちますか? 読み取り専用情報を一方にプッシュし、他方に注文情報を送信しますか? 変更・キャンセル等は？注文ステータスは戻されますか?
あなたは私がここに行くところを見ることができます。テクノロジーは二次的な質問です。
ビジネス ルールの問題と、2 つのシステムのスキーマ (および目的) が異なるため、これは標準的なデータ移動ではなく、「標準的な」回答 (レプリケーション、ログ配布など) のほとんどは検討の対象外です。 .
Microsoft BizTalkやScribe Insightなど、これを支援するために設計されたフレームワークがあります。ただし、これらは面倒で高価です。
C# またはお気に入りの言語で、SQL トリガーまたはスケジュールされたプッシュ (必要に応じて) に基づいて、カスタム キューイング システムを作成することはそれほど難しくありません。それはおそらく私が行くルートです。おそらく、一方が行った変更のキューを保持するための3 番目の「転送」データベースと、ビジネス ルールを適用してデータを他方にプッシュするためのモジュールが必要になるでしょう。
個人的には、この悪夢からできるだけ早く逃げたいと思います。あなたはまだこのオンライン注文を購入していないので、データを既存のアプリケーションと同期させておくことが、そのようなことをしない正当な理由になることをお勧めします. これを購入すると、データがめちゃくちゃになり、物事を適切に機能させるためにどれだけの時間とお金を費やしたかを永遠に後悔することになります. これは起こるのを待っている災害です。倉庫に何もないのに、在庫にあると思われるアイテムを注文することになります。こんなことしないで。これは、怒っている顧客と怒っているマネージャーの保証です。データベースにアクセスする独自のオンライン注文を作成する開発者を雇うほうが、時間の経過とともにはるかに安くなります。彼らがあなたの反対を押し切ってくれたら、履歴書を更新します。
個人的な経験から、他に選択肢がない場合にのみレプリケーションを使用します。スキーマを変更する場合は破棄する必要があり、爆発する傾向があります。
これには、おそらく SSIS を使用します。変換パッケージを構築するのはかなり簡単で、維持するのもかなり簡単です。
レプリケーションはうまく機能します。双方向の場合は、競合解決が組み込まれているため、これが唯一の実行可能なオプションになる可能性があります。
一方向の場合は、SSIS またはテーブルのトリガーで問題なく、リアルタイム (トリガーの場合) または任意の間隔 (SSIS) でデータをプッシュします。SSIS の利点は、それがバックグラウンド プロセスであることです。一方、トリガーは、データをプッシュしている間、供給側でトランザクションを保留する可能性があります。
大量のデータを移動しようとしている場合は、それを実行できる他の製品がありますが、大量のデータでない場合は、SQL Server ツールを使用したソリューションで必要なすべてを行うことができます。