製品データと在庫番号が頻繁に更新されるERPシステム（Navision）があります。製品の属性が更新されるたびに、この変更をService Brokerを使用して別のSQL Serverにプッシュする必要があります。私は検出にトリガを使用することを検討していましたが、それが最良の方法であるかどうか、そしてこれがスケーラブルかどうかはわかりません。私は更新がおよそ起こることを期待しています。 1秒に1回ですが、この数は2倍または3倍になる可能性があります。リアルタイムでのSQL Serverのデータ変更の検出と公開
フィードバックは高く評価されます。
各レコードの最終変更日の列を追加し、レコードが更新されるたびにトリガを使用してこの列を更新します。その後、最後のスケジュールされた実行後に更新されたすべてのレコードが処理されるように、毎日特定の時刻にスケジュールされたジョブを実行します（営業時間外の優先）。
ので、以下の項目は、DATETIMEデータ型を持つ表に新しい列も、LastModifiedDateは追加
トリガーでは1つの列しか更新されないため、テーブルのパフォーマンスには影響しません。また、更新ジョブを1日に1回だけ実行しているため、データベーストラフィックも削減されます。
1日に1回はリアルタイムではありません... –
ジェイコブ・Hと同様、リアルタイムである必要があります。 – Bjoern
はい、それは単なる選択肢であり、私たちのニーズに応じて任意の間隔を選ぶことができます。 –
_常に可用性グループ_オプションですか？ターゲットは正確なコピーか、何らかの変換が進行中ですか？ https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/active-secondaries-readable-secondary-replicas-always-on-availability-groups –
こんにちはBjoern、私はあなたを知っています具体的にはService Brokerに言及していますが、これはあなたの唯一のオプションですか？数年前と同様の要件があり、最終的にレプリケーションを使用することにしました。これははるかに迅速に実装する方法でした。いくつかの欠点があります：データベースの変更を伴うフォブをインポートする場合、パブリケーションからテーブルを一時的に削除する必要があります。さらに、リアルタイムの動作をシミュレートするには、エージェント間隔を高速ポーリングに設定する必要があります。 – Roeland
これに関してあなたのNAVパートナーと相談することを強くお勧めします。たいていの場合、この状況はC \ ALまたはNAVとのインターフェイスをとって統合するように設計されたプログラムを通じて行われます。誰かがあなたに答えを与え、彼らがNAVを知らない場合、あなたはそれを非常に批判的にすべきです。彼らはあなたのカスタマイズやビジネスロジックをあらかじめ知っていません。 –