1. Stored procedures and triggers are closely related. My general understanding is that a trigger is a hidden stored procedure, because it does not require parameters or explicit calls, and is often used without your knowledge. A lot of operations have been done in the case. From this perspective, because it is hidden, it virtually increases the complexity of the system. Non-DBA personnel will have difficulty understanding the database because it does not exist at all if it is not executed. 2. Furthermore, when complex logic is involved, nesting of triggers is unavoidable. If several stored procedures are involved, coupled with transactions, etc., deadlocks will easily occur. Debugging Sometimes, you will often switch from one trigger to another. The continuous tracing of cascading relationships can easily make people's heads ache. In fact, from a performance perspective, triggers do not improve performance much, but from a code perspective, it may be easy to implement business during coding, so my point of view is: abandon triggers! Basically, the functions of triggers can be implemented using stored procedures. 3. In coding, it is easy to read the code when the stored procedure display call is made, and the implicit call of the trigger is easy to be ignored. Stored procedures also have their fatal flaws↓ 4. The fatal flaw of stored procedures is portability. Stored procedures cannot be transplanted across databases. For example, if a stored procedure is previously stored in a MySQL database, it needs to be transplanted to Oracle considering performance. All stored procedures need to be rewritten.
I think it comes from two factors: 1- The stored procedure needs to be called explicitly, which means that you can know the existence of the stored procedure when reading the source code, but the trigger must be seen on the database side, which is easy to be neglect. 2- Mysql's trigger itself is not very good, such as the problem that after delete cannot have a chain reaction. I think triggers actually have the advantage in terms of performance, but they are not favored for the above reasons.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
1. Stored procedures and triggers are closely related. My general understanding is that a trigger is a hidden stored procedure, because it does not require parameters or explicit calls, and is often used without your knowledge. A lot of operations have been done in the case. From this perspective, because it is hidden, it virtually increases the complexity of the system. Non-DBA personnel will have difficulty understanding the database because it does not exist at all if it is not executed.
2. Furthermore, when complex logic is involved, nesting of triggers is unavoidable. If several stored procedures are involved, coupled with transactions, etc., deadlocks will easily occur. Debugging Sometimes, you will often switch from one trigger to another. The continuous tracing of cascading relationships can easily make people's heads ache. In fact, from a performance perspective, triggers do not improve performance much, but from a code perspective, it may be easy to implement business during coding, so my point of view is: abandon triggers! Basically, the functions of triggers can be implemented using stored procedures.
3. In coding, it is easy to read the code when the stored procedure display call is made, and the implicit call of the trigger is easy to be ignored.
Stored procedures also have their fatal flaws↓
4. The fatal flaw of stored procedures is portability. Stored procedures cannot be transplanted across databases. For example, if a stored procedure is previously stored in a MySQL database, it needs to be transplanted to Oracle considering performance. All stored procedures need to be rewritten.
I suggest not to use it at all.
This kind of thing is only used in projects and management systems with low concurrency.
If it is a user-oriented high-concurrency application, do not use it.
Triggers and stored procedures themselves are difficult to develop and maintain, and cannot be efficiently ported.
Triggers can be completely replaced by transactions.
Stored procedures can be replaced with back-end scripts.
I think it comes from two factors:
1- The stored procedure needs to be called explicitly, which means that you can know the existence of the stored procedure when reading the source code, but the trigger must be seen on the database side, which is easy to be neglect.
2- Mysql's trigger itself is not very good, such as the problem that after delete cannot have a chain reaction.
I think triggers actually have the advantage in terms of performance, but they are not favored for the above reasons.