Looking at Local Databases: Scenario I
We picked out two databases for review in our July issue assessment of "local storage" tools: VistaDB (my choice) and db4o (on the recommendation of one of our readers). While the review of db4o regrettably didn't make it into print, you can expect to see my hands-on take appear on this site in the next week or so.
Regardless of which products appear in print, the next step in my review process was to define what functionality I'm supposed to be assessing. Or, to put it another way, what do I mean by a "local database"?
My assumption is that, by and large, developers create applications (Web or desktop) that update some remote data store. In that scenario, the developer might still want some place to store data on the local computer: the local storage. The data could range from user preferences, to sets of "working data," to downloaded data to be used for offline analysis.
The first scenario for using local storage is to improve performance by eliminating the round trip to the server. The alternative to using local storage is to load data into memory (and there are a bunch of in-memory databases that support that scenario). However, I'm assuming here that the developer wants some form of long-term persistence: the developer wants the data to stick around. In some cases, especially where the developer is going to be analyzing the data offline, the amount of data may be too large to hold in memory or the user is expected to add to the local data store over time. A related scenario is where the developer has data that doesn't need to be in the central store (e.g. the user preferences mentioned earlier) and decides to keep it locally.
I'm keenly interested in this topic because I've written a client-side, multi-threaded Windows service that is busy receiving data from a variety of sensor devices (the service spawns a client app for each sensor). As the client apps gather this data, they upload the data through a Web service to our server-side application, which parses the data and stores it.
My client would also like to extend the functionality of the Windows service to provide some near-realtime services at the client. To support that, in addition to parsing the data on the server, we'd also like to parse the data at the service to provide faster access to the embedded data. Since the parsing process is table-driven, this is going to involve keeping copies of some server-side data at the client.
Posted by Peter Vogel on 06/09/2010