Processing in trigger (too much?)

  • Have an app that is used by 100+ users, probably 20 at a time.  Already use the update trigger to send e-mail to when flag is changed and now thinking of sending a report too when that flag is changed on the table. 

    What I am curious about is how does adding more code to that trigger effect performance.  I assume that it is only an issue when that condition is met with in the trigger and not otherwise.  But would it be better to write a service to monitor that table and batch up the changes and send the report that way?

    This is SQL2000.

     

    Thanks.

     

  • You probably will get better performance with using a seperate process/service to send out the emails. Then your updates are not going to take as long, or use as much server resources.

    You are however going to need some way of notifying or leaving a log for the service to know what changed.

    I've worked on some websites in the past that would send out emails to new users / certain account  or order changes / etc. It's far easier to have a different service regularly check the databse for changes and send out the emails.


    Julian Kuiters
    juliankuiters.id.au

  • I have a service that sends out the e-mails, printer or fax message.  I just have to insert a new row into a different table for that service.  The trigger modification would just get the e-mail address from another table and insert it into to e-mail table if the trigger flag was changed.

     

     

     

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply