Critical Criteria for Local Databases
In my last two blog posts (
here and
here, I discussed the scenarios that I'll have on mind when reviewing the two databases we've selected for our local storage reviews (VistaDB and db4o). This blog post and the next are about what I'll be looking for in the products (and also let me discuss why I'm not reviewing SQL Server Express or the Jet database that comes with Microsoft Access).
Interestingly enough, based on the scenarios that I described in my last post some of the criteria that I would be interested in when looking at a "real" database don't apply in this situation. To begin with, I'm not particularly worried about performance even though one of the scenarios focused on "performance enhancement". The database is going to have very few clients (probably just one), the amount of data is going to be small compared to what the remote database will be holding, and the client computer has only a single user at a time. In fact, I would suspect that most of the time, most of the data being accessed is going to be held in memory by the local database. My assumption is that performance is going to be very fast no matter what the underlying storage mechanism is.
What I am most concerned about is ease of deployment. This is why SQL Server Express isn't attractive to me: SQL Server Express is, essentially, a separate install from my application. Ideally, I want something that will automatically be rolled into my setup package and will silently install with the application (and without the user being aware of it). My test here is probably a one-touch deployment: If the database can install with my application in a download environment then I will be very happy.
Of course, because SQL Server Express does exist and is free, it also means that I'm looking for a relatively cheap solution. While I'm willing to pay for a simpler deployment package I'm not willing to pay a lot for that -- I'm probably looking in the $500 range for a product.
I'd also like a local database engine that I can roll out with each individual application, so a smaller footprint is preferable to a large one. I would also need these database engines to run simultaneously without stepping on each other's feet. SQL Server Express often takes up more disk space than the application I've created that uses it, and I've never even tried managing multiple instances of it on the same computer.
Reliability is critical of course: since this is running on a local computer I don't want to have to visit each computer to fix problems. That's difficult to test in a review situation, however, so I'll probably just have to take the vendor's words for that. Ubiquity is important, though. I'd love a single solution that uses the same library in both 32-bit and 64-bit environments.
While those are the essential criteria, there are some additional criteria that I'll be considering -- I'll cover them in my next blog post. And, as I work with the products, I'm sure that I'll develop additional criteria. It's amazing what a new product can teach you.
Posted by Peter Vogel on 06/15/2010