From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | hmidi slim <hmidi(dot)slim2(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: When use triggers? |
Date: | 2018-05-16 22:36:34 |
Message-ID: | 3c8d7297-265b-7bd2-3651-188deec0d0d0@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 05/16/2018 03:19 PM, hmidi slim wrote:
> 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?
Two benefits triggers and their associated functions offer, with the
understanding these are general statements:
1) Are in the database so tasks that always need happen do not need to
be replicated across the various interfaces that touch the database.
2) Also since they run on the server the data does not necessarily cross
a network, so less network bandwidth and better performance.
An example of a use case is table auditing. If you need to track what is
being INSERTed/UPDATEd/DELETEd in a table stick an audit
trigger/function on the table and push the information to an audit table.
As to managing, they are like any other code. I keep my schema code in
scripts under version control and deploy them from there. I use
Sqitch(http://sqitch.org/) which allows me to deploy and revert changes.
I use a dev database to test and troubleshoot triggers and functions.
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Benjamin Scherrey | 2018-05-16 22:42:28 | Re: When use triggers? |
Previous Message | hmidi slim | 2018-05-16 22:19:53 | When use triggers? |