StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>If I understand correctly, there are really two problems here: </p> <ol> <li>State of the system is represented by data coming from multiple data sources. As the result querying for state is expensive. </li> <li>The amount of data that describes the state of the system is large. As the result querying all data that describes the state is expensive.</li> </ol> <p>Standard patterns for solving these problems are to introduce a middle tier and use deltas to update the state. E.g.:</p> <ol> <li><p>Clearly, you don't want your Silverlight clients directly talking to backend systems. Not only that might be not possible, it is also very inefficient, since every client can ask same data source about its state. To avoid this standard solution is to introduce a middle tier that aggregates the data coming from all backend data sources, and also provides common interface to the clients. As the result the backend data sources will be polled only as often as needed (can be configured per data source in the middle tier), and also clients don't have to deal with specifics of those backed data sources. Plus you can implement indexing of the data in the middle tier, based on queries most common for the clients. </p></li> <li><p>Assuming that every record will have ID, client should request only deltas since the last update. One of the many patterns is to use a timestamp. E.g. when client initializes it requests the state of the system, and the middle tier sends that state, with timestamp. When client needs to update certain records, it provides IDs in the request, and the timestamp of the last update. Therefore middle tier will send only changes since that last timestamp, and only for requested IDs. If object has 15 properties, and only 3 of them were changed since the last timestamp, then update will contain only values of those 3 properties. </p></li> </ol> <p>As for push vs. poll - push is not automatically the best solution. It really comes down to a question of the trade-off between how often client needs to be updated and amount of traffic between client/middle tier. E.g. if state change is frequent but sparse (e.g. affects only a few properties at a time), and there's no requirement to update client's state immediately, client might prefer for changes to accumulate rather than receiving every single update, thus polling would be preferable. </p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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