Database licensing is a thorny subject. When opting for licensing an enterprise database product, you generally have two decisions to make: the edition you want and the licensing model you need to follow.

The required software edition may well be dictated by the architecture of the hardware it's to run on. For instance, if you want to use more than four processors in your Windows database server, you'll need the Enterprise edition of SQL Server 2008. The same applies to Oracle 11g. With Sybase ASE, for example, the Enterprise edition is required if you expect more than 256 concurrent connections.

In true IBM style, the model for DB2 is even more complicated. It combines simple restrictions, - such as the fact that the Workgroup Edition has a 16GB RAM limit - with the more complicated concept of a PVU, or Processor Value Unit. This metric is a function of the number of processors and their power, making things considerably more complicated.

The other half of the equation is the licence type. This is based on the nature of the application for which the database is acting as the back-end. Vendors all follow the same principle, with a licensing model depending upon whether or not you can predict the number of users for your application.

In an internal business application, the user count is generally predictable. You can therefore adopt a per-seat licensing model. In the good old days, you often had the choice of licensing a product based on concurrent user count (i.e. if you had 100 users but no more than 25 connected at once, you bought 25 user licences) or registered user count (in our example, you would require 100 licences). Oracle used to follow this model, but dumped the concurrent user concept a few years ago to stick with what it calls the "named user" approach. This measures the number of devices or people that have access to the database.

What Oracle started has now been picked up by other vendors. They all follow similar models, albeit with different names. For example, with SQL Server you'll hear talk of CALs, or Client Access Licences. Again, IBM appears to be the exception.

Although it uses an authorised user count, it also factors in the good old PVU: it sets minimum authorised user counts based on the PVU value of your server, which means that if you have a super-powerful box but only 100 users, you may still need to buy more user authorisations in order to meet the licensing minimum.

Web applications are trickier than companies' internal applications, since you can't confidently predict (or, more accurately, convince the software vendor) the likely user count for your server. You'll therefore have to adopt a per-processor licensing model. This allows an infinite number of users and considers the number of processors (or, as we've mentioned, the total processor power if you're a DB2 user), often with a fudge factor applied for multi-core processors (something Oracle does).

There comes a point where a per-processor licence becomes more economic than many dozens of single user licences. With SQL Server Standard Edition on a single-)processor server, this is around the 35-user mark, for example.

You also need to factor in the edition of the product you need (a single CPU version of SQL Server Enterprise costs a tad less than twice the price of the Standard version, for instance), and check that the needed edition even is available for your chosen licensing model. For example, Oracle 11g Personal Edition isn't available on a per-processor model.

There are a variety of additional factors to consider. The cost of maintenance, especially if tied to a particular vendor, can't be divorced from the overall cost. One needs to ascertain what changes can be made to the underlying platform without being hit by further costs. The growing rise in virtualisation within enterprises will also have an effect on licensing. many database vendors are geared more for the physical world than the virtual world.

It could be that a vendor's licence agreement requires a customer to specify a single processor within a machine. This means that a user who wishes to migrate from a virtual server to a physical one would have to pay for a separate licence for every processor on every server that the database runs on. Database companies aren't alone in struggling to cope with the move from physical to virtual, but anyone looking to virtualise a database server will have to start by asking some questions about licence agreements.