Note that there are some explanatory texts on larger screens.

plurals
  1. POHow to efficiently check if a result set changed and serve it to a web application for syndication
    primarykey
    data
    text
    <p>Here is the scenario:</p> <p>I am handling a SQL Server database with a stored procedure which takes care of returning headers for Web feed items (RSS/Atom) I am serving as feeds through a web application.</p> <p>This stored procedure should, when called by the service broker task running at a given interval, verify if there has been a significant change in the underlying data - in that case, it will trigger a resource intensive activity of formatting the feed item header through a call to the web application which will get/retrieve the data, format them and return to the SQL database.</p> <p>There the header would be stored ready for a request for RSS feed update from the client.</p> <p>Now, trying to design this to be as efficient as possible, I still have a couple of turning point I'd like to get your suggestions about.</p> <p>My tentative approach at the stored procedure would be: </p> <ol> <li>get together the data in a in-memory table, </li> <li>create a subquery with the signature columns which change with the information, </li> <li>convert them to XML with a FOR XML AUTO</li> <li>hash the result with MD5 (with HASHBYTES or fn_repl_hash_binary depending on the size of the result)</li> <li>verify if the hash matches with the one stored in the table where I am storing the HTML waiting for the feed requests.</li> <li>if Hash matches do nothing otherwise proceed for the updates.</li> </ol> <p>The first doubt is <strong>the best way to check if the base data have changed</strong>.</p> <p>Converting to XML inflates significantly the data -which slows hashing-, and potentially I am not using the result apart from hashing: is there any better way to perform the check or to pack all the data together for hashing (something csv-like)?</p> <p>The query is merging and aggregating data from multiple tables, so would not rely on table timestamps as their change is not necessarily related to a change in the result set</p> <p>The second point is: <strong>what is the best way to serve the data to the webapp for reformatting?</strong> - I might push the data through a CLR function to the web application to get data formatted (but this is synchronous and for multiple feed item would create unsustainable delay)</p> <p><strong>or</strong></p> <p>I might instead save the result set instead and trigger multiple asynchronous calls through the service broker. The web app might retrieve the data stored in some way instead of running again the expensive query which got them.</p> <p>Since I have different formats depending on the feed item category, I cannot use the same table format - so storing to a table is going to be hard.</p> <p>I might serialize to XML instead. </p> <p>But is this going to provide any significant gain compared to re-running the query?</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload