0

スキーマが異なる可能性のある2つの異なるデータベース（同じサーバー上）に2つのテーブルがあります。Table 1はmaster table、すべての更新が直接そこに送信されます。Table 2なる予定mirroredです：テーブル2をテーブル1と同じようにリアルタイムで維持する必要があります。

欠点は、テーブル2に追加の列、異なる列データ型、追加された主キー、追加された外部キーなどがある可能性があることです。ただし、これらすべてにもかかわらず、テーブル2は、特定のレガシーフロントエンドが生成するすべてのクエリをサポートする必要があります。

私は今日、トリガー内の2番目のデータベースのテーブル2に対して更新、挿入、および削除ステートメントを再実行しようとすることで、これらの「異なる」可能性のあるものをミラーリングできることを計画していました。トリガーが失敗すると、操作全体が失敗するため、理論的にはテーブルを同じに保つ必要があります。

ただし、トリガーをトリガーした実際のSQLステートメントを取得するのに行き詰まっています。

fn_get_sql


DECLARE @Handle varbinary(64)
select @Handle = sql_handle FROM master..sysprocesses WHERE spid = @@SPID
select text FROM ::fn_get_sql(@Handle)

ただし、これはステートメントではなく、トリガーのSQLを返します。

DBCC INPUTBUFFER(@@SPID)

これにより、SQLステートメントの最初の256文字が返されます。十分ではありません。

私の最初の質問は、SQL 2000でトリガーをトリガーするSQLステートメントを取得するにはどうすればよいですか？

私の2番目の質問は：これを行うためのより良い方法はありますか？レプリケーションを使用して、あるテーブルが別のテーブルとは異なるスキーマ（追加の列、列の異なるデータ型など）を持つテーブルをレプリケートできますか？

4

3 に答える 3

1

私は両方の質問に答えるために異なるアプローチを持っています。データベースに不要なオーバーヘッドが追加されるため、トリガーを最後の選択肢になるまで使用することは通常避けます。

トリガーとストアドプロシージャの比較

  • テーブルの関係、制約、インデックス、データベース内のストアドプロシージャを表示するのは簡単ですが、トリガーを表示するのは困難です。
  • トリガーは、クライアントアプリケーションアプリケーションからは見えないように実行されます。それらは表示されないか、デバッグコードで追跡できます。
  • トリガーを忘れがちであり、ドキュメントがない場合、新しい開発者がその存在を理解するのは困難です。
  • トリガーは、データベースフィールドが更新されるたびに実行され、システムのオーバーヘッドになります。システムの実行が遅くなります。

十分に言って、これが私がストアドプロシージャを好む理由です。エージェントを介してジョブファイルを作成できます（たとえば、30分ごとまたはその他の時間ごとに実行されます）。そのジョブファイルに挿入するためのロジックを使用できます。このようにして、データはtable2ほぼリアルタイムになります。

エージェントを作成するための参照： http：//msdn.microsoft.com/en-us/library/ms191128（ v = sql.90）
.aspx http://msdn.microsoft.com/en-us/library/ms181153
（v = sql.105）.aspx

于 2012-08-04T02:43:23.907 に答える
1

トリガーがどのように機能するかを誤解しているかもしれません。トリガーを起動させるクエリのテキストを見つける必要はありません。

SQL Serverトリガーは、insertedおよびと呼ばれる一時テーブルで動作します。このテーブルには、ステートメントdeletedの影響を受ける行の新旧バージョンが含まれています。および操作の場合、またはテーブルのみUPDATEがそれぞれ入力されます。詳細については、SQL2000トリガーのドキュメントを参照してください。INSERTDELETEinserteddeleted

table 2その中の行と。の間に1対1の関係があると仮定すると、トリガーを使用してを維持することが可能であるはずtable 1です。

あなたが考えるかもしれないもう一つの選択肢は、変換が単純である限り、table 2上に構築されたビューに置き換えることです。table 1ビューに元のオブジェクトと同じものがあり、必要なアクセス許可が付与されている限り、変更はクライアントアプリケーションに対して透過的である必要があります。データ型が変更された列で
他のテーブルを結合する必要がある場合、パフォーマンスに悪影響を与える可能性があるため、これをテストする必要があります。table 2

レプリケーションはこのタスクにはあまり適しておらず、table 1とtable 2が同じデータベースにある場合はまったく機能しません。レプリケーションのパブリッシャーとサブスクライバーは、異なるデータベースに存在する必要があります。

于 2012-08-04T06:41:29.613 に答える
1

レガシーアプリケーションが期待する構造にフォーマットされたマスターテーブルからデータを返すビューを使用することをお勧めします。遅延の問題はなく、データストレージの重複もありません。

于 2012-08-04T06:58:41.447 に答える