What’s up with triggers on views? What kind of patchwork monster is this?
I’m sharing something that I learned this week. It’s something I learned while talking to a friend at work. He wondered whether SQL Server had any feature similar to the rule system over at Postgres. (I thought no at first, but keep reading). You know, I continue to learn tons while talking to friends at work even though I’m the in-house SQL Server specialist. I don’t mind at all.
Back to the post. Here’s what I learned:
- I knew that insert/update/delete statements could be executed on views if the view was simple enough. If it was simple enough we call the view “updatable”.
- I thought that triggers couldn’t be defined on views but
- I was wrong and …
- I learned that not only are triggers allowed on views but INSTEAD-OF triggers will work on any kind of view, updatable or not.
Here’s what I mean.
create table A (id int primary key) create table B (id int primary key) go create view AB as select id, 'a' as tablename from A union all select id, 'b' as tablename from B go
If I were to try to insert rows into the view, I get this error message:
'UNION ALL view ~ is not updatable because a partitioning column was not found.'
Other views give other errors, but the message is the same: “You’re view is too complicated to be updatable”. That’s okay. I never really expected inserts to work on anything but the simplest views so I’m not too disappointed.
But like I said, here’s how you would make this view updatable – or rather insertable – with an INSTEAD OF trigger:
create trigger t_AB on AB instead of insert as if exists (select 1 from inserted where isnull(tablename,'') not in ('a','b')) raiserror (N'column ''tablename'' must be either ''a'' or ''b''' 16, 1); else begin insert A (id) select id from inserted where tablename = 'a' insert B (id) select id from inserted where tablename = 'b' end GO
Boom! No more this-view-is-not-updatable errors.
But When Would I Use This?
I thought of the perfect use case. This strategy helps with SCHEMA REFACTORING. Say your schema contains this table:
create table ANIMALS ( Name varchar(100) primary key, IsVertebrate bit not null, VertebraeCount int )
and you’ve decided to change it to look like this:
create table ANIMALS_BASE ( Name varchar(100) primary key ) create table VERTEBRATES ( Name varchar(100) primary key references ANIMALS_BASE(Name), VertebraeCount int not null )
After you’ve done that, you can create a view called ANIMALS with triggers to accommodate applications that still expect the old schema. That would look something like:
CREATE VIEW ANIMALS AS SELECT AB.Name, CASE WHEN V.Name IS NULL THEN CAST(0 AS BIT) ELSE CAST(1 AS BIT) END as IsVertebrate, V.VertebraeCount FROM ANIMALS_BASE AB LEFT JOIN VERTEBRATES V ON AB.Name = V.Name
Next create the insert, delete and update triggers. I only show the insert trigger here. The delete and update shouldn’t be too hard to write either.
create trigger t_ANIMALS_i on ANIMALS instead of insert as INSERT ANIMALS_BASE (Name) SELECT Name FROM inserted; INSERT VERTEBRATES (Name, VertebraeCount) SELECT Name, VertebraeCount FROM inserted WHERE IsVertebrate = 1;
Here’s a few ways that this helps:
- You might want to use this strategy when you don’t have control over every application using your database.
- This helps with migrations because applications are now free to expect the new or old schema. The applications can transition gradually to the new way of doing things.
Even if you believe every application uses only the new schema. You can still make sure gradually by logging whenever someone uses the old schema. Just add some logging statement to the definition of the triggers. You can log or track trigger use using any way you’re comfortable with. One suggestion is to use the user-settable performance counter via sp_increment_counter1 then Poof! You’ve got your own deprecated-features performance counter just like Microsoft.