Wise to use trigger to update another table?

Question

I have an Object table which is populated from an Integrated service (which I can change if needed) from another database. At certain points we need to manually add posts in another table ObjectObjectGroup (ObjectId, ObjectGroupId) which is needed if Object.ObjectType have a certain integer value. Since the integration service doesn't handle that kind of update, I'm thinking of adding a trigger to the Object table which in pseudo-code would be the following:

if Object.ObjectType = 10
    begin
        if Object.ObjectNumber like '<string pattern>'
        begin
            insert into ObjectObjectGroup values...
        end
    end

Is this setup wise, or is there a better way in terms of performance?

Answer 1

Mostly Copy/Pasting my response from this question on stackoverflow

Triggers can be very alluring, when you first start using them they seem like a magic bullet to all kinds of problems. But, they make "magic" stuff happen, if you don't know the database inside out, it can seem like really strange things happen (such as inserts into other tables, input data changing, etc). Before implementing things as a trigger I'd seriously consider instead enforcing the use of an API around the schema (preferably in the database, but outside if you can't).

Some things I'd still use triggers for

• Keeping track of "date_created" and "date_last_edited" fields
• Inserting "ID"'s (in oracle, where there is no auto id field)
• Keeping change history

Things you wouldn't want to use triggers for

• business rules/logic
• anything which connects outside of the database (eg a webservice call)
• Access control
• Anything which isn't transactional ( anything you do in the trigger MUST be able to rollback with the transaction )

Answer 2

Yes, it is wise. That's the purpose of a trigger actually, to perform needed actions after an insert/update/delete operation upon a table.

You need to take into account the fact that a trigger in MS SQL will not handle each row separately, but will handle all rows of the current transaction at once. So if an operation will insert 10 rows at once, you'll need to think your trigger's code to treat all rows at once.

Answer 3

Triggers are a powerful tool, and like any other tool you need to be careful when using them.

1. When you make a mistake in a trigger things can go DRASTICALLY wrong and unless you are running traces you won't realise...

2. They do 'magically' change/insert/delete data that the user of the DB (the current application/any future application/a developer doing a one off update) did not realise/intend.

The big problem is that after you've created the trigger, it is not obvious to other developers/users that a trigger is even there and what it does.

That said, they are a great tool for maintaining integrity of your data and for true Auditing of changes.

You need to ask yourself if the logic you want to put in the trigger sits best with the application(s) or within the DB, weighing up the risks on both sides (what happens if a new application comes along and doesn't enforce this rule?)