Sunday, May 30, 2010

Database

Of course an accounting program will use a database, so I had to choose one.

The program is designed for small customers, so most of the time there will be a single user configuration. Other customers will use the program in a LAN, but the number of users will be small. For this reason raw performance is not important, much more important is the ease of installation of the database software. It should also require no administration, since most end users will not be able to do it.
Another requirement is full support of the relational model, to make developing simpler.

Having decided to use open source software I had three choices: Firebird, MySQL and PostgresSQL. I decided for Firebird, mainly for two reasons:
  • Firebird is known to be simple to install and not requiring administration, at least for small installations.
  • Firebird is also available in an embedded version. Just drop some files in your program's folder and you have a working single user database. No need to separately install the database, no problem with existing database installations. This greatly simplifies setup for single user configurations. The embedded version is officially supported only for Windows, but it is possible to use it also for Linux and OS X.
I tested Firebird in a couple of open source programs and I am satisfied, so I keep using it.
At the moment I am still using version 2.0.x, even if version 2.1.x is available. The main reason is that the new version is compiled for Windows with Visual Studio 2005, so it requires a correct setup of the compiler runtime even for the embedded version. I could solve the problem compiling by myself with Visual Studio 2003 but, since version 2.0 is good enough for my needs, I prefer not to waste time. I will probably switch to version 2.5 that will have an embedded server that allows more than one connection.

The server install is available in two different choices: Classic and Superserver. This often causes some confusion for new users. Here are the main differences.
  • Classic uses a different process for each user connection. This uses more resources but each process can run on a different core/processor, so this version scales well with multiprocessor servers under heavy load. The different processes cannot share a single memory cache, so each one has its own.
  • Superserver uses a new thread for each connection. This uses less resources and it is possible to use a single cache, but the whole server runs on a single core/cpu and it does not use other ones even if they are available.
For normal usage, when the server load is small, the usual advice is: run Classic in Linux and Superserver in Windows. The upcoming version 2.5 will have another configuration better suited for heavy loads.

No comments:

Post a Comment