Taking the blinkers off

· by Steve · Read in about 4 min · (794 Words)

Developer.com is on my fairly modest set of RSS feeds, and occasionally it has something interesting in it. In general I have found that over time, online articles on development from this sort of place have become less and less useful to me, probably because most of them are of the ‘getting started’ type, and I’ve been a developer for long enough that often I either already know what the article is about specifically, or I can see that it’s just another technical take on an old idea. When I use a new tech for the first time I still find them useful as a quick start quide, and very occasionally there’s an article that is genuinely interesting, but most of the time, the more interesting stuff tends to come from books, academic papers and  the personal blogs of other experienced developers, simply because I’m generally looking for deeper material. I guess most developers feel the same after 10+ years.

So, I was skimming and saw this article: Choosing the “Right” DBMS Engine. It piqued my interest because I’ve used a lot of databases over the years (Oracle, SQL Server, DB2, MySQL, PostgreSQL, Access, IDMSX, Btrieve, probably others I’ve forgotten) and as with anything, you only use a small number of them extensively at any one time so you quickly get out of date on the pros/cons of each (particularly as I’m not in the business software world any more so my DB usage has decreased). So, I thought this would be an interesting article to read if it compared and contrasted a few based on the current situation.

Imagine my disappointment when the article only considered editions of SQL Server - ostensibly 7 entries in his table but they’re all variants of basically the same thing; only SQL Server Compact Edition is actually a different product, the other 6 are the same thing with variations enforced via licensing. Er, hello?

Now, I realise the author is an ex-Microsoft guy and says he’s only going to talk about what he knows best, which is Microsoft DBMS engines - but in that case he clearly should have titled the article ‘Choosing the “Right” version of SQL Server’. ‘SQL Server’ is not and has never been a synonym for ‘DBMS Engine’.

I’m probably sounding like a pedantic old git now, but it does irritate me when I meet developers who, when faced with a problem that needs a database, seem to think SQL Server is the obvious choice without even considering anything else. Don’t get me wrong, it’s a nice enough product (which I’ve used for some projects in the past), but __it’s been a lot of years since it was so cheap compared to the competition that it was a throwaway choice to use it. Sure there’s free versions, but obviously they’re there as loss leaders to get you to buy the rather expensive higher end versions, just like every other commercial database. It’s worth looking around for a sec and really evaluating your options.

My personal experience is that they all have different pros and cons which are much more deserving of an article than the relatively minor differences between editions of SQL Server. SQL Server is generally dead easy to administer which has a number of pros (and also cons - it means it’s very easy for less well trained people to set up a poor database and the business doesn’t realise until it’s much harder to fix), as opposed to something like Oracle which always needed a fairly high level of training thanks to its esoteric terminology and toolsets. Conversely Oracle tended to give you bucketloads of tweaking ability and automation options which when you got into a tight spot was very handy. To some extent those positions have converged now, but it’s probably still broadly true. When I used DB2 it had some really nice media handling features that nothing else I tried had, like being able to do a query on video length or average brightness of images. Then you have all the open source offerings, some of which are really rather good these days and cover a broad range of ease of use versus advanced features, like MySQL, Firebird, PostgreSQL and even SQLite for those super-small embedded cases.

Basically if you’re in the market for a database, there’s never been a better time to shop around for what works best for your particular case, and not to be suckered into paying for something you don’t need - the market is very competetive. This article completely ignored that fact, even though it did claim to only consider Microsoft options in the interests of brevity, I think it was a disingenuous way to present a discussion supposedly about choosing a DBMS engine.