Comparison of code location detection (C # code vs storage process)

Cause: a large number of conditions must be detected before a leave record is saved. The detection can be completed in three aspects: client and server C #Code, Database storage process

This problem has been plaguing me. Where is my detection code written? I only vaguely feel that the storage process may be better, so I moved the detection content preparation to the storage process, but then I found more problems, so I compared the two (only limited to my current capabilities) to see where they are.
(The client's JS Code will be added later, because the client can not detect, or the client can detect more, the server must also perform the detection again)
C # code SQL storage process
Good reusability
Maintenance-good readability
Maintenance-poor debugging
Poor programming convenience
Testing
Performance-Running Speed
Performance-good network exchange
Poor adaptability to changes
Well deployed
Low Complexity
Poor User Experience

Reusability:
C # Code cannot be used in VB6, while the Stored Procedure detection logic can be simply and directly reused by VB6. Later I checked it, and a DLL is generated in C, call VB6 (check the complexity)

Http://read.newbooks.com.cn/info/175321.html

Maintenance-Readability:
The annotation function is available to all users. The Code folding function is available in C #, and the SQL statement benefits are directly seen in SQL, without the need to establish connections or close connections, but C # can be compensated by functions. IfProgramPerfect. Connect to the SQL statement and execute the statement to obtain the returned value. It is as simple as eating, so C # is better than SQL.

Maintenance-debugging:
Check and modify the variables during debugging, and modify the code while debugging. These SQL statements are much inferior to C #

Programming convenience:
This mainly refers to smart prompts, code format standards, and code syntax errors. This is why SQL is much inferior to C #

Test:
If you want to perform an automatic test on the stored procedure in SQL, it is very easy to implement, because the stored procedure is less associated. The subroutine test in C # seems to have a lot of problems, including building sessions, requests, and other content, so you can take a little bit of caution.

Performance-running speed:
Using the C # detection condition does not need to be moved to the database, so it does not need to be connected or other operations (then suddenly think of it, if you do not need to use the database detection, in fact, the JS end is complete, will the JS test + storage process test = OK), the speed will be faster, and the detection of the storage process, at least need to call a connection to the storage process this action.
However, for the data to be used in the database, the C # speed must not be faster than the storage process.

Performance-network exchange volume:
This refers to the network exchange volume when the database and IIS are not on the same server, similar to the running speed. For those that do not need to connect to the database, C # is good. For those that do not need to connect to the database, good SQL.

Adaptability to changes:
Change refers to the addition of a detection condition. If the entry parameter does not change, you only need to change the storage process. C # The code is modified, compiled, and deployed.
If the entry parameters change and the storage process changes, the current operation user will encounter an error. You can use a certain scheme to save the entry parameters of the storage process from being adjusted. The scheme is as follows:
When we want to pass the parameters passed by the client to a storage process, we find that the number of these parameters is the most frequently changed, sometimes one more, sometimes one less, there is no way to keep the parameters constant. The code is not subject to changes in the number of parameters. Later, I thought of a way to throw the client parameters to a table, and then pass the record ID to the storage process, set it to a specific parameter before processing.
1. Save the obtained parameters to a table, or even a string.
2. When the stored procedure is called, only the ID of the record is passed.
3. The stored procedure obtains information from the table.
This is precisely because of this problem.Article.

Deployment:
Since I now know how to deploy C # without interrupting the current user, modifications to the content of C # will not have a special impact, and the two will not have much difference in deployment.

Complexity:
If the stored procedure is used, it also needs to pass through the C # code section, so that an extra layer is added out of thin air to increase complexity.

User Experience:
It refers to the user's situation, which is not easy to implement using the storage process, and C # is relatively convenient.

Summary:
After comparison, it is obvious that my hunch is wrong. After some shortcomings of C # are overcome, C # is much better. In the future, we will strengthen the reuse, automatic testing, and adaptation to changes, so that we can write a large number of detection statements in C # without hesitation.