Better do it with trigger, so you only code it once. Otherwise the code will be repeated everywhere in your accessing program, much more difficult to maintain. Even if you capture the logic in library, the programmer still migth forget to call it when he should.
Also trigger is usually faster.
| [reply] |
Only problem is if you are using MySQL, then you won't have triggers until version 5.
As a side note, I recently had to change an application over to using MySQL instead of Sybase, and I certainly wished the original developer had not bothered with triggers. :-)
| [reply] |
Class::DBI provides triggers in a database transparent way.
Although transaction support doesn't really fit the way it works, it does function and you can use it.
As a bonus, instead of using triggers to sold the original posters problem, you _could_ subclass it and override the class methods for creating, deleting and updating objects.
| [reply] |
I certainly wished the original developer had not bothered with triggers
I understand your sentiment, that it's a pain to migrate to a database with less functionality than the application currently uses. This is a legitimate problem, and deserves consideration, but I have to disagree with you in the general case. I think it would have been foolish of the original developer not to use triggers, if they were the right tool for the job. (You will probably reply that, in your case, they were not the right tool. That's fine, but I am talking about the general case here.)
Not using all the mechanisms available in a database engine, just for the sake of "portability," strikes me as rather bizarre. That's almost like avoiding the use of map in a Perl program because it does not exist in C. Sure, the application might one day be ported to C, but one shouldn't limit the use of legitimate features based on what might "one day" happen.
| [reply] |