I’ve been toying with the idea to get alternative for a ‘local database’ for a standalone or even embedded database. In the past I used Jet a lot but since Microsoft is abandoning it (like some many other things including being successful… 😉 ) I started looking for alternatives. Lately I’ve been using SQL Compact a lot. It is actually nice to use and because of it SQL server roots developing for it isn’t that difficult. However, it still has one drawback that most other ‘real’ database systems have – it requires a separate install which must also be maintained separately – think about software and security updates here.

I’ve been working on a genealogical database for an uncle of mine and the current database is still an MDB file. One of the reasons moving away from this format is that Jet is not supported on 64-bit anymore – and Microsoft is not making any effort (nor would I expect it) to port the Jet database drivers to support 64-bit. Then, even the new format for Access requires installing office. This brings me to another reason I want to steer away from installing ‘separate’ things just to support a database – he (uncle) like so many other ‘normal’ computer users have no idea how to manage or maintain a database system especially if things goes wrong (and they have a habit to with normal users using them – I wonder why…). So what could I use to suit these requirements??

In the past I have considered using a plain xml file as a data store but abandoned the idea for various reasons. Things like xml’s ‘bloatness’ or lack of real database features counted against it. Now I find myself again re-looking at this but perhaps with different expectations. I don’t think using an xml file as a general database would be a good idea but for a scenario like mine it might just work – perhaps.

The question is of course how to implement this database idea. An xml file is just that – a plain text file that  has no functionality by itself. There are existing database systems that are based on xml – see nxd databases. However, none of the well established ones really support .Net as is. On the other side I don’t want to go and develop a whole new database management by myself. Perhaps there is a middle\hybrid way of doing it. From past experience I know that .Net DataSets can persist to an XML file and internally it can be seen as a mini database with support for real data types, indexing, relationships, default values including things like autonumbers etc. Transactionality is not required as the system will be single user, single instance based. Some downsides are that xml is very bloated, you cannot load just part of the data – it is either load everything or nothing and you have to be careful with which encoding you use (because genealogical data usually contain non-ascii characters 🙂 ).

Thus, I’m in the process of investigating how feasible it is to use either a plain or typed DataSet as the base of a data layer for an application. The application itself will still use normal ‘domain’ class structures to handle data internally but the data access layer will rather interface with the DataSet. I thought about just using the domain classes and serialization to persists them straight to (xml) file but then simple functionality provided by the DataSet objects would have to be coded manually (and I’m too lazy now or not in tha mood).

So stay tuned while this idea develops.