Shulou(Shulou.com)06/03 Report--

[this article is transferred from the blog Garden author: Shishiyan original text link: https://www.cnblogs.com/13yan/p/3539938.html]

Software developers are initially trying to do something.

When one day, developers have mastered the way of development, and the implementation of functions has become commonplace.

So people start to think about more questions, and performance is a problem.

Developers with 2-4 years of work experience usually struggle with this issue, but their understanding of performance is very different because of the uneven foundation.

Maybe we cared too much about performance in those years.

Myth 1: O/RM tools affect performance

It is found that many people like to use O/RM tools to discuss performance and are afraid of the loss of performance after the introduction of ORM tools.

However, as far as I know, the performance of some mainstream ORM tools are pretty much the same, and the comparison between ORM tools is not a performance problem, but a question of usage habits.

Compared with native ADO.NET, ORM will definitely lose some performance, but it brings the advantage of improving development efficiency.

As far as I know, many colleagues do not have many users of OA, ERP and other systems.

Pay too much attention to performance issues, that is, get less than 5% of the special cases, refuse to improve development efficiency in most cases.

No one says that if you use ORM, you must use ORM everywhere to the end.

Myth 2: stored procedures can improve performance

There is nothing wrong with using stored procedures. If you use stored procedures too often, debugging will be annoying.

1. Add breakpoints in the program, and then copy the variables to the stored procedure to add breakpoints for debugging.

2. Rely too much on stored procedures, the database contains business logic, business logic is scattered in the program and database, and the readability of the code is lost.

3. Calling stored procedures does make many SQL statements become a stored procedure name and parameters, reducing network transmission, but in many cases this performance is not required.

4, the business logic is written in the stored procedure, and if you use the object-oriented language, it will be used as a process-oriented language, which is disadvantageous to the development of complex projects.

Misunderstanding 3: big data's performance problem

As long as contact with millions or tens of millions of people think it is big data, some people even think that the MSSQLSERVER database will fail if it encounters tens of millions of users.

In fact, if the monthly data growth in millions of levels, then these are small data for the query, the use of partitions and query constraints is relatively easy to solve.

In the same way, MSSQLSERVER can handle tens of millions of levels of data.

What is the real performance problem with the database?

The real performance problem, I think, is database design at the macro level and SQL tuning at the micro level.

Summary

ORM tools should not be rejected on performance grounds, nor should stored procedures be abused.

Pay attention to performance from the design stage, do not worry too much about performance problems and lose development efficiency.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.