hmidi slim <hmidi.slim2@xxxxxxxxx> writes: > HI, > > I'm working on a microservice application and I avoid using triggers > because they will not be easy to maintain and need an experimented person > in database administration to manage them. So I prefer to manage the work > in the application using ORM and javascript. > However I want to get some opinions and advices about using triggers: when > should I use them? How to manage them when there are some problems? I think triggers are generally best avoided. They do have a purpose, but like regular expressions and Lisp style macros, they are abused more often than used appropriately. When used correctly, they can help to ensure your code is robust, clear and easy to maintain. The big issue with triggers is that they are really a side effect of some other action. As such, they are obscure, easily missed, difficult to debug and often frustrating to maintain. In nearly 30 years of working with different databases, I've rarely found triggers necessary. As mentioned by others in this thread, they can be useful when you need low level auditing and like all guidelines, there are always exceptions, but in general, they should usually be the last choice, not the first. Database functions on the other hand are extremely useful and probably something more developers should take advantage of. There are far too many applications out there which are doing things within external application code which could be handled far more efficiently and consistently as a database function. The challenge is in getting the right balance. My rule of thumb is to develop under the assumption that someone else will have this dumped on them to maintain. I want the code to be as easy to understand and follow as possible and I want to make it as easy to make changes and test those changes as possible. Therefore I prefer my code to consist of simple units of functionality which can be tested in isolation and have a purpose which can be understood without requiring a knowledge of hidden actions or unexpected side effects. If a function cannot be viewed in a single screen, it is probably too big and trying to do too many different things which should be broken up into smaller functions. regards, Tim -- Tim Cross
