Having spent some years helping to define the IT strategy of a couple of well-known commercial organizations, you'd think I'd be able to tell you exactly the logical process by which an organization, or IT project, settles on their choice of database system. In fact, no. I've only rarely experienced an IT project where a rational decision was taken about the database product to use. Often it is difficult to detect anything more than a sort of 'group instinct'. Occasionally, it would be based on the existing skill set, or even the groundswell of opinion from the developers.

Sometimes, it seemed to be the result of what we called, in code, the 'lobster lunch'. The higher echelons of the organization would return from a trip to a vendor, dazzled by a smooth marketing pitch and fine seafood, and announce the choice of database technology shortly after. This was often before deciding on the aims of the project, and its database requirements.

Sadly, there is a wide difference between what the marketing people will tell you are the virtues of a relational database system and the aspects that appeal to the average commercial organization. In the broad view, fancy features hold little appeal to the IT manager, especially if they drift from the core purpose of a database. Instead, they value responsiveness of queries, ease of use and rapid delivery of applications. From this perspective, an expensive database system can be a lot cheaper on the budget of an IT project. Most of the considerable costs of maintaining a leading relational database system are incurred almost invisibly by the vendor in pursuit of performance, conformance, and reliability at scale; You are paying for the virtues you need rather than the ones that initially seem attractive.

There are also other 'hidden costs' in purchasing a database system. For example, if the database system you're considering still uses arcane and inconsistent ways of implementing procedures and functions, then the extra development costs of building a database application can soon outweigh the up-front license costs. If you must hire 'consultant' developers to fix inexplicably slow query performance, you are soon losing control of your budget.

You will quickly regret an injudicious purchase of a database system. It is a bit like buying a fancy-looking car at a knockdown price. It looks the part in the driveway, but what you're really buying is the hassle and distraction of frequent trips to the garage.

Phil Factor