ここでは、トリガ内で動的SQLをテストするためのいくつかの簡単なスニペットを示します。それは動作するように見えます!
-- create the tables
create table Readings
(
id int identity,
tbl varchar(10),
some_val int
)
create table Z01
(
id int identity,
some_val int
)
create table Z02
(
id int identity,
some_val int
)
go
-- create the insert trigger
CREATE TRIGGER [dbo].[TRG_InsertTest]
ON [dbo].[Readings]
AFTER INSERT AS
BEGIN
declare @sql nvarchar(max)
select @sql = isnull(@sql, '')
+ N'INSERT INTO ' + quotename(tbl) + ' (some_val) VALUES (' + convert(varchar(10), some_val) + ');'
from inserted
exec sp_executesql @sql
END
GO
-- some testing data
insert into Readings (tbl, some_val)
select 'Z01', 10 union all
select 'Z01', 11 union all
select 'Z02', 20
select *
from Readings
select *
from Z01
select *
from Z02
私はトリガーが、彼らはあなたのデータベースのバックグラウンドで実行する前にダウンしてコンパイルする必要があるため、これは可能であるかわかりません。 –
これは通常、壊れたデータモデルの兆候です。つまり、一般的に扱いたい同一の構造を持つ複数のテーブルがあることです。通常、* data *としてモデル化されるべきもののいくつかは*メタデータ*としてモデル化されています。私。より一般的なデータモデルでは、 'Z01'は、このデータのすべてを含むべき単一のテーブルの(あるカラムの)データとして現れるはずです。 –
問題は、1秒ごとに読み取り値を取得する複数のセンサーがあるため、1つの表にそれらを結合したくないということです。そうしないと、表が大きくなりすぎる可能性があります。 **読み**テーブルは、特定の条件が満たされたときにのみ散発的に更新されます。私は条件がどこにあるのかというと複数のトリガーを持つという解決策を見出しましたが、それが最善の方法であるかどうかはわかりません。 – mkb