And that's where SQL Server's In-Memory OLTP (online transaction processing) tables come in. This reduces the caching problem by providing a single point of contact for all updates: The data in memory at the server is the "right" data.
The second-best solution is, when you go to your database server, hold your data in memory on your database server rather than on your hard disk. Server-Side Caching with Memory-Optimized Tables In that scenario, it becomes difficult to determine what the "right" data is. However, if your data is volatile and being updated from multiple clients or applications, then caching can create as many problems as it solves because the data held at each of the individual clients can be different. The ultimate solution to this problem is, of course, caching: Store data at the client rather than accessing it from your database. When you go to your database server, you're doing both of those things (though, to be fair, SSD drives help with the second problem). The two slowest things you can do in application development are to issue a call to another computer, and read or write to your hard disk. I've said it before and I'll say it again: If you want to speed up your application, don't look at your code, look at your data access.
0 kommentar(er)
