Discussion: is it a good practice to use triggers to adapt to changes in business processes?

my project is in maintenance, due to the legacy requirements or design issues in the early stage, and frequent request changes made by customers, frequent changes are miserable. It is very troublesome to perform large-scale tests after each change. Many of the requirements are to add or modify some of the steps in the multi-step database operation. For example, the record was deleted directly before, and now it is suddenly proposed that the deletion should be backed up to another table; in the past, the application form was simply reviewed, and now it has to be archived and transferred to another table, and so on.

in theory, changes to requirements must be reflected in Code changes. Sometimes, to be lazy, you can start from the database directly. If you add a trigger to a business process, you can achieve the same effect. The advantage is that you do not need to re-compile the code, which is very convenient, and our project is useless ORM , all are handwritten SQL , easier to write to the database. The downside is that the Code does not know the trigger. The implementation of a business flow is placed in two places. If a problem occurs in this process, the trigger may need to be modified, and it's just staring at the code.

In the project, the database isOracleA trigger is generally used to write a recordIDI always feel that if this is the only way, I will not make full use of him. Do you think it is feasible to use a trigger to adapt to changes in the business process? If so, what standards should be used? In addition, where can triggers be applied in projects?

My point of view is a little too small.