Our system is a summary of the SP (stored procedure) when designing:
SP is most suitable for this large SQL combination of SQL, because in placing the combination of the code, it is easy to maintain in the SP, and the speed is fast.
But if it is a large number of users access, there is no way to improve it, but do it in the intermediate layer code (such as CLB). And it is easy to port to another database.
That is to say, our management system has fewer users, and SP can be used in the report; and the communication system (to extend performance) uses code combination SQL facilitates future expansion.
Therefore, it is not like the previous discussion, it is not a SP or a combination of SQL statements. Just look at you, summarize a few points:
1. If there is more complex business logic, SP is not recommended (this requires the programmer to be very familiar with SQL to read business)
2. Consider the use of SP
3. The system is large, considering the convenience of the system, the hierarchical properties of the system are not recommended to use SP
4. Touching the need to handle transactions, rollback and other content recommendations SP
5. Consider long-term maintenance, debugging and checking the complication, version control is not recommended to adopt SP
6.SP must have a document corresponding, otherwise there is more than the system, I don't know what the stored procedure is doing!
