Database Abstraction

I discovered an interesting view of database abstraction some few days ago when I was browsing for a blogger service to register into. It was titled The Illusion of Database Abstraction Layers or Classes. My first thought was "oh dear..." and my second was that I was so going to write about that once I got my blog up and running.

According to the author "DB abstraction layers will mostly hide the specific interface semantics between the application and the database." This is true of course since it is the very definition of abstraction to hide complicated parts of the program from the user. That is why they are so useful because you the programmer do not have to worry about the specific of the database implementation and can concentrate on what is more important, such as pleasing your customer.

But what the author seems to have completely forgotten is that there are a great many levels of abstraction and most of them are not complete. And indeed this is a good thing. It is not the library's mission to do everything for you but simply to make it easier. I know, like most programmers who have worked with a lot know, it is a painful process to build an interface that talks with multiple DBMSs. But the fact that the database abstraction library does not support it does not mean that it does not work. It only means that it works to a certain point, which is not entirely the library's fault because, like the author mentions, compatibility between DBMSs is loose at best and horrifying at worst.

Personally I have never really understood why people have an obsession to write applications that run with at least half a dozen DBMSs anyway. I am sure it looks great on promotions when you can say that a product runs on Mysql, PostgreSql, MsSql, Oracle, and whatever DBMS you could think of but does the product really need it? I am going to go out on a limb here and say that in fact most products do not need such support. I have known a large number of applications that were both popular and did well in business and which did not support more than two DBMSs at most. If you think about it carefully, the more DBMSs you support the less you will support them all. Because like the author mentions, the compatibility between the DBMSs is very bad. If you support only a small set of DBMS, lets say two at most, you can better take advantage of the features that they have and make your product all the more better.

It is the old rule of business to target your products to as a specific audience as possible, instead of the whole world. This is slightly harder in the open source world because by tradition open source software is developed with a specific audience in mind and hence they must be as flexible as possible. However I would still give open source developers the same advice. A targeted audience is better than a wide audience. Do not worry about those that you cannot please. Someone will eventually cough up a similar software to yours that will those who you could not target.