More Local Database Scenarios
As I mentioned
in my last blog entry, we picked out two databases to review for our "local database storage" review for the July issue timeframe: VistaDB and db4o. This blog (and the last) answer the question, "What do I mean by a local database?" I discussed one of the scenarios (performance enhancement) for local storage in my last blog.
A second scenario where local storage is needed is to support processing when the network connection to the application's remote database isn't available: continuity of service. By downloading and caching key data on the local computer, the application can continue to work even if the most recent data (back on the remote server) isn't available.
Obviously, this is only going to be possible if the data is relatively non-volatile. If the application can't refresh the local data from the server the local data goes stale and, if the data is volatile (changes frequently), bad things happen to good programs. A variant on this scenario is using local storage to store the user's changes until the connection is made when the user's data can be uploaded to the central database.
As I mentioned in my last blog, I have an interest in these tools (as I do in most of the tools we review, quite frankly). My application is a Windows service that uploads data from sensors at the client to a central Web service. To handle continuity of service each client has two threads: one that writes data to a flat file and another that reads from the file to send the data to the Web service. When we lose the connection to the 'net (and we have) the file just grows until the connection is re-made. I don't object to using flat files but a local database would make this part of the service considerably easier to maintain.
We're also considering creating a server-side version of this application where working with flat files isn't an attractive option. For the server-side version we'd rather keep all of our data (including the data currently going into the flat files) in a database. Rather than have two codebases (one using a client-side flat file and one using a server-side database) we'd rather have a single code base that uses the same storage throughout.
Which leads to the criteria for the products under review. That'll be my next blog post, though.
In the meantime -- do these scenarios sound sane to you? What else (if anything) should a local database support?
Posted by Peter Vogel on 06/10/2010