SQL Differences between stored procedure and triggers

Question

I'm having trouble understanding the difference between a stored procedure and a trigger in sql. If someone could be kind enough to explain it to me that would be great.

Thanks in advance

Solution 1

A stored procedure is a user defined piece of code written in the local version of PL/SQL, which may return a value (making it a function) that is invoked by calling it explicitly.

A trigger is a stored procedure that runs automatically when various events happen (eg update, insert, delete).

IMHO stored procedures are to be avoided unless absolutely required.

Solution 2

Think of a stored procedure like a method in an object-oriented programming language. You pass in some parameters, it does work, and it can return something.

Triggers are more like event handlers in an object-oriented programming language. Upon a certain condition, it can either (a) handle the event itself, or (b) do some processing and allow for the event to continue to bubble up.

Solution 3

In respect to triggers in SQL Server: a trigger is a special piece of code that automatically gets executed when an event occurs in the database server.

DML triggers execute when a user tries to modify data through a data manipulation language (DML) event. DML events are INSERT, UPDATE, or DELETE statements on a table or view. These triggers fire when any valid event is fired, regardless of whether or not any table rows are affected

We can create trigger like this:

CREATE TRIGGER TriggerName
ON [dbo].[TableName]
FOR DELETE, INSERT, UPDATE
AS
BEGIN
    SET NOCOUNT ON
END

A stored procedure is nothing more than prepared SQL code that you save so you can reuse the code over and over again. So if you think about a query that you write over and over again, instead of having to write that query each time you would save it as a stored procedure and then just call the stored procedure to execute the SQL code that you saved as part of the stored procedure.

• We can do lot of programming stuff in a stored procedure and execute again and again.
• We can create procedure which take the input process and give the output
• We can handle the error through try catch
• Stored procedures can be nest and call again and again with nested calling
• It's more secure

We can create a stored procedure like this:

CREATE PROCEDURE dbo.Sample_Procedure 
    @param1 int = 0,
    @param2 int  
AS
    SELECT @param1,@param2 
    RETURN 0;

Differences in both of then

• Trigger can not be called manually where stored procedure can be called manually.

• Trigger executes automatically when event happens and can be use for reporting and data protection from deleting or dropping the table and data from database. We can prevent from trigger. On the other hand, a stored procedure has to be called by somebody.

• A stored procedure can be called from front end (client application) but trigger can not be called from client application.

Solution 4

Some differences between triggers and procedures:

1. We can execute a stored procedure whenever we want with the help of the exec command, but a trigger can only be executed whenever an event (insert, delete, and update) is fired on the table on which the trigger is defined.
2. Stored procedure can take input parameters, but we can't pass parameters as input to a trigger.
3. Stored procedures can return values but a trigger cannot return a value.
4. We can use transaction statements like begin transaction, commit transaction, and rollback inside a stored procedure but we can't use transaction statements inside a trigger
5. We can call a stored procedure from the front end (.asp files, .aspx files, .ascx files, etc.) but we can't call a trigger from these files.

Solution 5

A trigger fires after an insert, update, or delete. A stored procedure is a server-side program that is run when you invoke it.

View more solutions

Comments

[Mikael Eriksson]

stored procedure. trigger.

[Bohemian]

What is the relevance of "Transact SQL"? Do you think that SQL Server is the only database in the world?

[Dynamiite]

So lets say for example we have to notify user when a product is not returned would you use a trigger or a stored procedure?

[Dynamiite]

So can you call a stored procedure from within a trigger?

[Bohemian]

No. Data not being returned is not an "event". Also, doing things outside the database like notifying users is difficult from a stored procedure. You should use application code for this.

[marc_s]

WHY would you recommend to avoid stored procedures at all costs?? Seems like a rather unfounded and too broad statement, in my opinion, stored procedures do have valid and very legitimate use cases!

[Bohemian]

@marc_s read the linked answer for why. Ok, I'll tone it down a little.

[marc_s]

Not sure if this really is the case for MySQL or Oracle - but when I need to do some kind of a mass operation, I'd much rather do that on the server (SQL Server in my case) in a well crafted and well written stored procedure and just return a result, rather than pulling gigabytes of data to the client, computing something and then getting just a tiny little result out of this....

[marc_s]

I would much rather say to avoid triggers if ever possible, since they (a) don't scale well, (b) you can't control if and when and how often they fire, and (c) their functionality is often "hidden" and forgotten by developers and supporters, making them an endless source of trouble and nasty surprises....

[Bohemian]

@marc_s I used to think that too. I actually wrote the entire production server business logic using stored procedures. I though it was "more efficient". But now I realise they are the work of the devil. Read the link - it's all there. "Efficiency" isn't everything. There are much broader concepts that are more important than raw efficiency.

[Bohemian]

@marc_s in a recent project, I created a trigger that fired on data changes to numerous tables to populate a table that was a queue for an ESB that was being added to a legacy system. Using a trigger was the only, and best, way to intercept changes. I'm not totally anti SP/trigger, but you use them only where you have to

[random_user_name]

Consider improving both the format and content of this answer. This is a trigger - great. What's a stored procedure? Also learn how to use the markdown to create a nice-looking list.