Improve SQL Server database performance from the client

Welcome to the Windows community forum and interact with 3 million technical staff. Third, use high-speed cache on the client to improve server performance. We all know that cache is also used during database design. Cache is a module in the middle of the operating system memory. Because reading data from the memory is much faster than reading data from the hard disk

Welcome to the Windows community forum and interact with 3 million technical staff> go to third: use high-speed cache on the client to improve server performance. We all know that cache is also used during database design. Cache is a module in the middle of the operating system memory. Because reading data from the memory is much faster than reading data from the hard disk

Welcome to the Windows community forum and interact with 3 million technicians>

　　Third: use high-speed cache on the client to improve server performance.

We all know that cache is also used during database design. Cache is a module in the middle of the operating system memory. Because reading data from the memory is much faster than reading data from the hard disk, you can log the data that supports the query into the cache in the database, so that the server performance can be achieved.

Now, some program developers have gone further. In the client application, it can also be used as a cache. The client cache is similar to the server cache. When a user queries the price change record of a purchase order, even if the user turns off the table, the queried data will still be stored in the Client Cache for a certain period of time. When the user needs this data next time, the client will not directly query the data from the database server, but will first find the data from the client cache. The statement is fed back to the server to extract data from the server. In this way, you can share the Server pressure on the client to improve the performance of the SQL Server database.

However, if the cache is set on the client, it is best to add a button to clear the cache on the application software. In the case of silent writing, we may want to know the result of the change, not the last one. For example, we changed a certain amount on the server. However, the data is still cached because the client has just queried the data. Then, it still shows the status of the instance that has not been changed. In this case, you need to clear the cache to view the changed content in a timely manner.

Fourth: Implement table integrity constraints on the foreground.

If you implement table integrity constraints in the background database, if a field cannot be blank, you need to go through many steps. For example, the client program first passes the result to the table. during storage, it finds that a field is empty and does not meet the requirements of Table integrity constraints. The database refuses to save this record, the database server sends the result to the client. Obviously, this processing mechanism is quite troublesome. Is there any simple solution?

In fact, if we implement table integrity constraints through the front-end client application, it may be more advantageous to the database performance. For example, a field in the front-end client interface cannot be blank. In this case, we can add a limit when developing the foreground application. When this field is blank, it cannot be saved. Data that cannot be stored on the front-end client is certainly not transmitted to the back-end database server. By implementing table integrity constraints in the foreground, we can reduce the processing process. It can ensure that the content transmitted to the background database conforms to the integrity constraints.

In addition, the default value is also convenient in the client application. For example, when I develop a database, I need to have a record creation and update date. You can create a default date for these two fields. Now the question is whether to implement it in the foreground client program or in the background database? I prefer the front-end. Because at the front-end, the client will directly pass the current default value to the server, and the server will simply save it. Instead of triggering the storage process of the server's default date.

In short, I believe that when we consider improving database performance, we need to work together between the client and the server. This method may give us some unexpected gains. After use, everyone may express their sincere sighs and agree with the author's practice.

[1] [2]