Should you use sql specific statements?

It seems there are two camps when it comes to SQL and how to do database optimizations – the “generic camp” and “the specialist camp”. While I don’t consider myself an extremist, I am absolutely in the specialist camp and this little post is an explanation of why.

SQL is a generic database langauge . There are a few different standards in use (the language has progressed over time), but the core of the SQL language is pretty much the standard in most databases. It’s probably also standard – in any database – that the SQL standard has been extended with database-specific extensions which provides optimizations, functions or other options not available in the SQL standard.

Using these database-specific extensions while developing your application ties your application/website to the specific database, and if you need to switch database at some point, your need to rewrite your applications SQL statements, so they aren’t tied to that specific database.

While this may be true I haven’t once during my ten years of web development, once had to switch database either during development nor during operations. I’m sure it happens in some cases, but I’m also sure that those cases are pretty rare, and if you need to go over your application and change the SQL statements, spending time on that is probably one of the easiest parts of a “technology switch” (ie. switching from Mysql to an Oracle cluster).

In most cases, using and utilizing database specific extensions can provide you with some easy optimizations and boost the performance significantly. While you probably can avoid using them, you’ll probably need to move the functions into you application or make more complex database queries. Optimization is usually an evolution, not a revolution. If your performance isn’t as expected, the first step is usually where are the bottlenecks, where can we optimize the current state of things – not switching database, not switching programming language.

Before you become a SQL purist, do make a calculated guess on what the “database switch probability” is. In most cases it’ll probably be less than 1%, and if this is the case, all common sense should tell you to use the tool available to the best of your ability, right?

  • I have to disagree a bit about the probability of switching databases. Many people may have to switch one of the open sources alternatives to one of the large-scale commercial databases. Mostly because they “started small” and later needed some of the advanced capabilities in the commercial products.

    One of the biggest issues in converting databases is not related to the SQL language as such – I totally agree. But if you started implementing business logic in your databases using stored procedures / triggers you might get caught in some really differences between the products 🙁

  • I have to disagree a bit about the probability of switching databases. Many people may have to switch one of the open sources alternatives to one of the large-scale commercial databases. Mostly because they “started small” and later needed some of the advanced capabilities in the commercial products.

    One of the biggest issues in converting databases is not related to the SQL language as such – I totally agree. But if you started implementing business logic in your databases using stored procedures / triggers you might get caught in some really differences between the products 🙁

  • I have to disagree a bit about the probability of switching databases. Many people may have to switch one of the open sources alternatives to one of the large-scale commercial databases. Mostly because they “started small” and later needed some of the advanced capabilities in the commercial products.

    One of the biggest issues in converting databases is not related to the SQL language as such – I totally agree. But if you started implementing business logic in your databases using stored procedures / triggers you might get caught in some really differences between the products 🙁