SQL Server misunderstanding: 4th-day DDL trigger is the INSTEAD trigger

Misunderstanding #4: DDL triggers (introduced after SQL Server 2005) are INSTEAD triggers

This is wrong

The implementation principle of DDL triggers is actually an AFTER trigger. This means that a DDL operation is performed first, and then the trigger captures the operation (of course, if you write Rollback in the trigger, it may also be rolled back ).

Rollback also means that the trigger is not as lightweight as you think. Let's look at the following example:

Alter table MyBigTable ADD MyNewNonNullColumn VARCHAR (20) DEFAULT 'Paul'

If a DDL trigger for a defined for ALTER_TABLE event exists, or a broader event such as DDL_TABLE_EVENTS. The DDL code above will add a new column to each row of data in the table, and then trigger the operation. If your trigger has rollback to prevent DDL operations, the cost is not small (if you do not believe it, you can check the logs generated after this operation ).

Of course, a better way is to set GRANT or DENY permissions for ALTER, or simply allow DDL operations through the stored procedure you created.

However, although DDL triggers can disable DDL operations, they are expensive. The benefit of a DDL trigger is that some users are allowed to perform operations such as modifying tables, so I do not mean that the DDL trigger is not allowed, but should be used with caution.

Kimberly has a good blog on DDL Triggers: "execute as" and an important update your DDL Triggers (for auditing or prevention )".