Databases are very important to me (I don’t get out as much as I should), so on my list of key decisions a company can make, choosing a database engine ranks right up there with the choice of an operating system — if not above it. What’s odd, though, is that often the engine underpinning an organisation’s databases is not actively chosen at all: it is a historical accident.
If you’re old enough, you’ll remember the days before companies had computerised databases, when paper ruled the Earth. At some point in the 1980s, at the typical business, a head of department — finance, let’s say — went off to a conference and came back enthused about ‘computerisation’. He or she then chose a financial system for the company. And the chosen system would run on whatever database engine the vendor’s product designers had selected.
If the company was extraordinarily well organised, when the time came to choose a human resources database, part of the specification was that it had to run on the same engine (though this wasn’t always possible with proprietary systems). Mostly, however, the required level of organisation was not on offer, and the company ended up running a variety of database engines.
As the cost of supporting multiple engines became apparent, a company might decide to standardise on a single engine — and in fact this might be the point that your company has finally just reached.
Who gets to choose the database engine?
When you do get to that point, one of the burning questions is who should make the choice? Is this essentially a technical decision or a management one? In the best of all possible worlds, the decision is taken at the management level after full and frank discussion with the technical staff, who should be intimately involved in the decision-making process. Unfortunately, very often, this doesn’t work well in practice. So rather than simply pretending all is sweetness and light, let’s look in detail at why choosing a database can be so fraught.
Databases are technical bits of kit, so it seems obvious that the technical staff need to be consulted. And because in many cases I sit on the technical side of the fence, naturally I support that viewpoint. But technical doesn’t always equate to logical; database engines can sometimes be to technical people what blue suede shoes were to Elvis — something that other people should keep their hands (or feet) off of.
The truth is that database people can be very polarised in their views. In my experience, they are usually hopelessly enamoured of the first (and possibly only) database engine they learned to drive. If you think the Linux vs. Windows brigades are vociferous, try spending the evening in the bar at a database conference while the Oracle database zealots square up to the SQL Server fanatics. Watching is fun, but don’t get between them.
Therefore, when you ask the database professionals at your company for an opinion, you shouldn’t automatically expect an unbiased answer. What you may get is a pseudo-technical answer that sounds convincing but doesn’t actually cut the mustard. For example: “We can’t use SQL Server because it doesn’t scale.” Or: “Oracle is way, way too expensive.” There is usually a historical basis for these beliefs but both time and the products have moved on, and many of the old arguments no longer hold true.
So, am I suggesting that database people are all stupid, narrow-minded and bigoted? Err, that would be a ‘no’ on several counts.
For a start, I’m a database person myself and — as I’m sure you can tell — I’m intelligent, open-minded and completely even-handed. Secondly, of course good database people don’t behave like this, but pretending that none of them do is absurd.
Thirdly, we can view such behaviour as bigotry or passion: the former is a sin, the latter a virtue. Database people are often genuinely passionate about their jobs and will work long hours ensuring that their favoured database engine performs well for the company. The value of this passion should never be underestimated — indeed it should be nurtured and encouraged. But we also need to be aware of both sides of the coin.
Why are you choosing a database engine?
A company usually finds itself approaching the question of database engine choice from one of three positions:
- It’s running a number of engines and wants to standardise on one.
- It previously standardised on a single engine but is considering a change, perhaps pushed into this position by an increase in the cost of licences.
- It has yet to choose, maybe as a result of being a start-up company.
Taking them in order then, it is very important that the first choice is not made on the basis of basic functionality such as scalability, robustness or speed. Instead, it should be made on the extra functionality that competing database engines now offer. Clearly, a range of other factors should also influence the choice, such as the engines on which your mission-critical applications will actually run. But don’t waste time agonising over functionalities that won’t help you differentiate between products.
If you’re in the second position and you can achieve significant savings on licensing costs, the obvious choice is to change your engine. However, don’t underestimate the passion of your database professionals for their favoured engine. Recently, I came across a case where a company had made such a change. The savings made perfect financial sense and would easily have paid for the migration and retraining costs. However, some of the database team objected and went into ‘passive resistance’ mode.
During the technology trial period, the dissidents put minimal effort into making the new system work, which caused the schedule to slip disastrously. At the same time, they were busy applying for other jobs, getting them and leaving the company. Although the financial impact is hard to quantify, the fact that the database team was in disarray for several months while the vacant posts were advertised and filled and new incumbents brought up to speed did nothing to improve the organisation’s bottom line.
Savings aren’t the only factor in choosing a database
Obviously, this single example doesn’t mean that you can never change database engines: companies can and frequently do. But it does suggest that the issue is more complex than simply looking at the quantifiable savings; there are people-management issues to take into account as well.
If you’re in the third position you can make your choice on the same basis as for the first one: not on the functionality exhibited by all the major contenders but on specialised features that fit your business requirements. You’re also well placed to negotiate hard, playing one manufacturer off against the others on your shortlist.
And last but not least, you should take a look at the cost of employing database professionals to work with the various products you’re considering – some technologies are more expensive to support than others.
Dr. Mark Whitehorn specializes in the areas of data analysis, data modeling and business intelligence (BI). Based in the UK, he works as a consultant for a number of national and international companies and is a mentor with Solid Quality Mentors. In addition, he is a well-recognized commentator on the computer world, publishing articles, white papers and books. Whitehorn is also a senior lecturer in the School of Computing at the University of Dundee, where he teaches the master's course in BI. His academic interests include the application of BI to scientific research.