May 25, 2017 at 10:23 am
Comments posted to this topic are about the item The Rate of Change of Data
Best wishes,
Phil Factor
May 30, 2017 at 2:13 am
I'm pretty comfortable with aggregation tables being used for one thing or another, and have a reasonable sense of when to use them.
I'm interested in your metadata about caching requirements ideas though, I've never been that sophisticated on that front, i.e. I've used the standard practice of it being the responsibility of the client. I think I can understand what you mean, but would there be any chance of an illustrative article on that one? Unless of course I've already missed it.
May 30, 2017 at 2:39 am
I've not written up on the subject, probably because it is a bit obscure. The caching requirements metadata are more simple. This tells the application how long it can retain the data for an entity before it needs to refresh-how volatile the data is. Additionally, there is a log table that the application can call to report when the data for an application-level entity (calendar, latest news, stock changes, whiteboard) was last changed. Finally, there is server-side cacheing which I use it predominately where the application is receiving document data( e.g. XML, JSON or YAML) from the database. It needs a logical interface between the application and database. Essentially, this document is only updated when the underlying data changes. The data for frequently requested 'documents' is held in a table and it is that which is sent to the client rather than recalculated on every request.
It is difficult to talk about this in general terms since techniques vary so much from application to application.
Best wishes,
Phil Factor
May 31, 2017 at 8:31 am
I'd like to see SQL Server add a build-in feature for caching result-sets. Today, Riak is commonly leveraged by web application developers to do this in the middle layer, but it requires interfacing with the Riak API. What I'm proposing for SQL Server result-set caching is similar in concept to query plan caching; it would be keyed on a query plan hash, and if the same query + parameters are executed, and if the underlying tables havn't changed, then it would simply return the previously cached result providing response time at warp speed.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply