When I last reported on UvMoney, I had just created a web interface for entering transactions. Since then, I'm pleased to report that all five of my bank readers now use direct HTML access instead of AutoHotKey scripts, and they have been working more-or-less happily for months. (Every now and then banks will upgrade their web sites, though, which is a pain.) The system works pretty well, but now I'm starting to make some more changes.

My main focus now is on data management. When I started this project, all the ledger data was stored in a single XML file. My intention was to keep the data transparent and avoid any kind of proprietary formats (*cough* Quicken and MS Money *cough*). XML seemed like the perfect choice. However, as I'm sure you know, XML is much better as an archival format than an operational format. That is, if you want to edit one record in the middle of a file, you have to read the whole XML file into memory, make the change, and then write back the whole XML file to disk. Of course, with today's modern computers, I can actually keep all the data in memory at once, so I only have to worry about writing the data to disk, and writing to disk is quite fast these days. But efficiency is not my main concern here: Concurrency is what I'm worried about.

My wife and I have both been adding transactions to UvMoney, she from her computer and me from mine. Both of us are updating the same XML file. It hasn't happened yet, but it is inevitable that someday we will both end up trying to update the file at the same time, and that will throw an exception and one of us will lose our changes. For just the two of us, that's annoying but not catastrophic. But what would happen if this application is ever used by more than two people? Say, in a small or medium-sized business environment? Complete catastrophic failure, that's what will happen.

Now I'm sure you're saying to yourself, "Well why don't you just implement some kind of semaphore scheme?" Sure, I could do that. But the user experience wouldn't be very good. All I could do is tell the user, "Hey, you can't save right now because somebody else is using the file." That's not very friendly. Also, the saving occurs automatically, typically after a web page postback. So the error would have to appear when a page loads. Or I could delay until the file is available again to save it, introducing a puzzling sluggishness.

All of which brought me to start implementing a "real" database backend.

Choosing the right database is a difficult issue. If this project were just for myself, I would probably use SQL Server Express. But I originally wanted this to be a distribution-friendly project that anyone could download and use. That's one reason why I liked using the XML file for storage; you could start using UvMoney right out of the box without setting up a database or anything.

For now, I've chosen MySQL as the backend. Why? In my mind, there were really only three viable options to choose from: A Jet (Access) database, a SQL Server Express database, or a MySQL database. The Jet database has the considerable advantage of not requiring the user to install and setup an additional product, and also the data is contained within a single file for easy portability. I've used them before with success. However, I don't think I have to tell anyone that Jet databases aren't very fast, and the Jet engine lacks features. SQL Server Express would work fine, but I think it would be difficult to install without user intervention. That leaves MySQL.

That being said, I am coding the data layer in such a way that it should be possible to hook into other backends without too much trouble. I can still see value in allowing the use of a Jet database or even XML files. I'm hopeful that the database backend can be a simple configuration option, eg. "Use XML file," "Use Jet database file," or "Use MySQL database." That should cover everyone from novices to somewhat advanced users.

(P.S. This was actually written in October, and I've since discarded the database backend again. :)