Triggers: One vs Many

  • This is a task I am sill investigating for a final answer but I will like your input before I say my results so that there is minimum bias on the replies:

    Scenario:

    You have a fairly big trigger on a table and bacically all it does is to keep aggreagations and journals on other tables.

    The question:

    Would it be better to split the trigger into 10 (about all the different actions taking place) or should it stay as one big thing

    I'll really appreciate your comments on this one.

     


    * Noel

  • How critical is it to update the aggregations on the other Tables ? Example; RealTime, every 1 hour etc...


    Kindest Regards,

  • I suppose it depends on actions taking place i.e. are any of the aggregates dependant on the previous in the trigger?

    If I can speculate as to what MrSQL is getting to, is that perhaps none of them need to be in a trigger if they're not required run-time, therefore reducing the transaction time, but then I suppose that they wouldn't be in a trigger.

    Just as long as none of the actions won't raise an error, I'd say keep them together unless you change the individual statements regularly, then it'd be better to have them seperate for administrative purposes.

    I have experienced that multi-transactional sprocs take longer to compile and are more difficult for sql in terms of the execution plans but it's all relative.

    But I'll be waiting for your final analysis.

    Max

    Max

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

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