Can't we omit database triggers? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 8 years ago.

As Wikipedia says

Database Triggers are commonly used to:

• audit changes (e.g. keep a log of the users and roles involved in changes)
• enhance changes (e.g. ensure that every change to a record is time-stamped by the server's clock)
• enforce business rules (e.g. require that every invoice have at least one line item) etc.

ref: database triggers - wikipedia

But we can do these things inside the Business Layer using a common programming language (especially with OOP) easily. So what is the necessity of database triggers in modern software architecture? Why do we really need them?

Answer 1

It might work, if all data is changed by your application only. But there are other cases which I have seen very frequently:

1. There are other applications (like batch jobs doing imports etc.) which do not use the business layer

2. You cannot use plain SQL scripts as a means for hotfixes easily

Apart from that in some cases you can even combine both worlds: Define a trigger in the database, and use Java to implement it. PostgreSql for examples supports triggers written in Java. As for Oracle, you can call a Java method from a PL/SQL trigger. You can define CLR based triggers in MS SQL Server.

This way not every programmer needs to learn PL/SQL, and data integrity is enforced by the database.

Answer 2

Think about the performance. IF this is all to be done from the application, there are most likely a lot of extra sql*net round trips, slowing down the application. Having those actions defined in the database makes sure that they are always enforced, not only when the application is used to access the data.

When the database is in control, you have your rules defined on the central location, the database, instead of in many locations in the application.

Answer 3

Yes, you can completely omit database triggers.

However, if you can't guarantee that your database will only be accessed from the application layer (which is impossible) then you need them. Yes, you can perform all your database logic in the application layer but if you have a table that needs X done to it when you're updating it then the only way to do that is in a trigger. If you don't then people accessing your database directly, outside your application, will break your application.

There is nothing else you can do. If you need a trigger, use one. Do not assume that all connections to your database will be through your application...