SQL SERVER – Disadvantages (Problems) of Triggers

One of my team member asked me should I use triggers or stored procedure. Both of them has its usage and needs. I just basically told him few issues with triggers. This is small note about our discussion.

Disadvantages(Problems) of Triggers

It is easy to view table relationships , constraints, indexes, stored procedure in database but triggers are difficult to view.

Triggers execute invisible to client-application application. They are not visible or can be traced in debugging code.

It is hard to follow their logic as it they can be fired before or after the database insert/update happens.

It is easy to forget about triggers and if there is no documentation it will be difficult to figure out for new developers for their existence.

Triggers run every time when the database fields are updated and it is overhead on system. It makes system run slower.

I do not use triggers. In my whole career I am able to get my work done using Stored Procedures instead of Triggers. (Implementation and Architecture changes are required if either of is to be used to support business logic).

57 thoughts on “SQL SERVER – Disadvantages (Problems) of Triggers”

I agree with your list… I find Triggers very annoying in a Database. You have no clear view of whats going on under the hood. But i think the last point of triggers is the only supporting argument, and not one against Triggers.

If you need to ensure that something happens EVERYTIME a field is updated, then you should use a trigger! Thats there only “purpose in live”. So you either need to close down your DB so noone can access the tabels directly, or you need to implement a trigger. Thats the only way you can verify that a certain rule will be obeyed. The performance argument is still valid. You need to make sure that your trigger only fiers when the field is actually updated (Hint: update foo set bar = 1 where bar = 1 is an update on foo.bar… so compare the values).

One of my tables has UPDATE trigger with thousands lines of statements and using “IF UPDATE(column)” to bypass unnecessary running of the Trigger for certain field updates. What I experience is that even though the trigger bypasses the lines when it encounters updates to those specified fields, the response is taking long which I presume is caused by trigger compilation. If I disable the trigger, the response is fast.

Can you tell me is it a good practice for a trigger to contain tousands of codes. Or what do I do in order to make updates on the specified columns to run fast?

I have created one After Update Trigger in Sql server 2005.
But My Problem is When I am Going to Update more then one column at a time Trigger given me error message while this trigger is working fine for one record updation

Trigger is Follow.

I have create trigger for when I update Test5 table at the same time entry will be done in Test1 table.

Triggers can now be selectively disabled giving the developer more control over how the triggers are used. Triggers can be disabled for a single user, all database users, a single trigger or for a single table. Changing the state of a trigger will take place immediately and in most cases will be persisted until explicitly changed. The exception to this is when disabling triggers for a specific user, in this case the disabled setting will only apply until the user disconnects.

This functionality can be very useful when doing bulk INSERT, UPDATE or DELETE operations where triggers could potentially affect performance. This may also be used for the ADSSYS or other system users to avoid audit type triggers during automated data changes.

Such all think is ok with Trigger but according to me the maser drow back of Trigger ( or all the data base object ) is when we swich over one data base to another data base than it need to re-create. If such all the logic is written in front hand than there is no need to write Trigger logic in other data base.

EX:- Suppose current my project is running with ASP.net and using Oracle as Back end if i some of other client need that project in Sql Server as back end than all the DB object must be re-write in Sql server.

I used triggers in one of my project to maintain the logs.. I can keep track when and who has updated/inserted the values in tables. Secondly what values are updated to what in cases of updated triggers can be easily traced.

Hi
Mr Pinal Dave
I Have problem in SQL Server 2005
I Have 3 tables for Example tblA , tblB And tblUser
tblA have Relation with tblB and he is perent for tblB
and tblUser have relation with 2 table tblA and tblB
and he is parent for tblA and tblB
when I want to create Relation SQL Server 2005 trow
error with this comment :

Introducing FOREIGN KEY constraint ‘FK_tblB_tblUser’ on table ‘tblB’ may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
Could not create constraint. See previous errors.

if i Set ‘Cascade Rule’ to ‘NoAction’ and Set ‘Enforce Foriegn Constraint’ to ‘No’ then for this reason i have 2 solve
1- use transaction to update
2- use Trigger to Update

please tel me wich one is better
tblA and tblB grow 1 million record per year

Trigger is very powerful TSQL Command and should be used very carefully.

You cant implement Parent-Child relation with foreign key constraint, if you have your parent table in one database and your child table in other database. In this case, you can use triggers to implement foreign key relation ship.

You cant have a check constraint on a table, if you want to check a value that refers to two other tables. You can implement the same with Triggers. (You can also use a combination of Check Constraint and a function to implement the same)

You can actually start a Job inside a Trigger. If any event occurs, and you want to set a response to that event, you can set it through a trigger.

There are many more advantages of Triggers.

Starting from SQL Server 2005, We also DDL Triggers, there are NO if and No Buts to not use them… they are very very helpful… just take a look or google (DDL Triggers in SQL Server 2005) on web to know more about them.

In the event where a primary needs to be generated on the fly, I can’t see how can you do it without a trigger, unless you reove the primary key and run a stored rpc every time you insert anything, but it leaves us with the same scenario. I would think the greatest disadvantage is the difficulty to track or not “forget” that there is a little detail running behind the scenes…

As the name imply the code of AFTER trigger executes after completing the trigger firing statement while code of INSTEAD of tigger executes instead of firing statement.
AFTER triger is used mostly for implementing business logic and auditing while INSTEAD of trigger is used on updatable views.

I totally agree with you on this.
To add to your thoughts, triggers are misused most of the times thereby affecting db performance. Also, all app logic should be part of the application process flow to keep things simple and visible like you said, which makes debugging easier as well.
I have trouble explaining this concept so some people.

Thanks for the heads up – it sounds like people are using Triggers for things which they probably ought not to… for example cascading foreign key relationships.

I work in an environment where we do lots of bulk imports into clusters of child/parent tables, and if we had triggers going off each time we did anything we would have 1) a very slow environment, and 2) many many erroneous table links.

On the other hand – we also rely extensively on non-clustered indexes in order to make our reporting work in a realistic amount of time.

Is it appropriate to use a trigger to disable all table indexes before committing an UPDATE or INSERT statement, and then to rebuild the indexes AFTER the statement processes?

Hello,
How can I we get the values of the records being updated on the Table and not get updated due to Where Condition
CREATE TABLE [dbo].[Test](
[id] [bigint] NULL,
[description] [varchar](50) NULL
)
GO
INSERT INTO [dbo].[Test]([id],[ description])
Values (1,’SQL2005’)
GO
Update [Test] Set [description] = ‘SQL2008’ where [ID] = 3
In above case I need to write a trigger where I can find the Value of Field Description Which is SQL2008,
Instead of Trigger gives the values but only if the Records are updated

I have seen to ways of tracking data change(DML).
1. Using Triggers
2. Keeping columns in same table for Added Date, Added By, Modified Date, Modified By.

Using approach(1), I can write trigger for Insert/Delete/Update on each table to log changes and hence can apply Foreign key relationship and other constraints like Unique key constraints on all the tables as per requirement.

But I didn’t understand how it is possible to apply various constrains using approach(2).
Since I have to make composite unique key and have to consider many more columns.

Is there any design issues in database tables. What is the suggested way for approach(2) to log data.

Which approach is better.

Also I have come to know from some of my collegues that Triggers do no fires on bulk insert queries is it true.

Nice article, your articles always manage to stay current throughout the test of time!

There is one thing I use triggers for and that is when I need exact audit records of every change made to each record in a table – although I hasten to add that what I do within the trigger is get the batch of records which have been changed and call a stored procedure from that record set so as much of my code as possible is easily visible under procedures.

Is there a better way for me to capture audit records or is a DML trigger the right thing to do here? I implemented it in my dev version of a program (as we have a lot of people here who would have access to the DB so I can’t rely on application-side auditing, sadly!) but if I should have taken another approach then I would prefer to implement it before I move to live!!

your Last Statement is wrong
“Triggers run every time when the database fields are updated and it is overhead on system. It makes system run slower.”

————————————————————-
i have “emp” table that have id,name columns

i created a trigger that is below-
————————————-
alter trigger trgEmpInsert
on emp after insert
as begin
declare @a int
select @a=id from inserted
insert into emp1(id) values(@a)

end
——————————————-
Here Emp1 is another table that have the same schema as emp

i add a new column in emp table as below-
——————————————————–
alter table emp
add country1 varchar(33)
—————————————-
when i checked the emp1 table after this we does’t get any row f inserted from trigger .
————————————————-
Before Answering any concept please practical it in SQL server .

let me know if i am wrong .

——————————————————————-
all Query which i am used to test the above concept
——————————————————————-

I was asked in an interview as to how you will perform auditing without use of trigger.
We used trigger to save the old data with timestamp in another table called audit
Is there a way to not use trigger and still have audit data?

These was my idea avoiding trigger/stored procedure until now I am developing a cloud-base web application where network traffic is one key issues. I have to revisit dealing some business requirement/constraint/rule that can be applied and executed on server side.

New way to handle trigger/stored procedure effectively and maintainable is implementing unit test while modeling database. The DB Unit Test is the same concept and practice as JUnit which implement Test Scenario, Test Case, Expectation, Result and Assertion. The difference is using SQL instead of Java.

The how-to is while modeling data , you must build sample data to test your logic. Some requirement / constraint/ rule can be made by trigger/strored procedure at this stage. A best practice in dealing with creating table, trigger, stored procedure is not to use graphical modeling,but simply write SQL file containing DDL/DML script with full description and comment.

You must create script of sample data to create sample data for both programmer and you as a DBA to make DB Unit Test. We then write DB Unit Test script to test against these sample data. After the test we will have test log to represent every test case have been test and passed. This help ensure table structure , trigger, stored procedure have been made right and work properly. This practice could help in maintenance when come new more requirement or change.

Hi Dave,
We want to save history (audit trail) for some of our tables (on update). The structure of the table in which we want to save the history data is –
Pk, TableName, ColumnName, OldValue, NewValue, TablePk, ModifiedBy, ModifiedOn

We thought of using triggers to save the history in this table. Can you please suggest what is the best approch to save history data in this table without using trigger.

Also, in some of the tables we are doing mass update, Audit trailing is required for mass update too. User may upload a file to update multiple records in one go. The process we followd for bulk update is –
1. Read the data from the file.
2. Bulk copy to a temporary table.
3. Update the original table from the tempory table (using a single stored proc).
4. Flush the temp table.
How can we do the audit trailing in this situation?

Community Initiatives

About Pinal Dave

Pinal Dave is a Pluralsight Developer Evangelist. He has authored 11 SQL Server database books, 17 Pluralsight courses and have written over 3200 articles on the database technology on his blog at a http://blog.sqlauthority.com. Along with 11+ years of hands on experience he holds a Masters of Science degree and a number of certifications, including MCTS, MCDBA and MCAD (.NET). His past work experiences include Technology Evangelist at Microsoft and Sr. Consultant at SolidQ. Follow @pinaldave
Send Author Pinal Dave
an email at pinal@sqlauthority.com

Email Subscription

Enter your email address to subscribe to this blog and receive notifications of new posts by email.