Some thoughts in regards to Dennis' observation that triggers are slow. I would kinda expect them to be slow. After all, they are (essentially) little programs that get run each time a record is changed. Even if the trigger did nothing, some overhead is expected for processing each record.
I'm curious about performance differences between traditional update programs and triggers. Writing 500 000 records with and without a trigger only tells us that triggers have overhead, but how would you measure the performance difference of moving actual functionality from a traditional program to a trigger? For example, let's say I have a data-mangling function implemented in a subroutine that's called from various programs during record updates. If I were to rip the data-mangling subroutine out of the entry programs and move it to a trigger, what kind of performance would I gain/lose? This would be a more meaningful metric to me -- if the trigger was significantly slower, I would probably avoid triggers. Has anyone out there performed any trigger benchmarks like this? I'm guessing "no". Another consideration is maintenance programming. Triggers can simplify both the initial design and maintenance of software systems, which is why they are popular in other databases. Like a lot of things in technology, they can be misunderstood and abused. Used wisely, triggers can help in managing software complexity. REX ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
