In response to an article written by Jeremy Zawodny on his blog, titled "Database Abstraction Layers Must Die!", and in particular, to some of the commenters who were denigrating any kind of abstraction. While I totally agree that generic abstraction, such as Pear and ODBC and the Smarty PHP template system are ridiculous and cause more problems than they solve, it is critical that code be organized into separate layers such that the presentation scripts are completely insulated from where the data originates. Here is my argument for abstracting data sources...

It's a DATA abstraction layer, not a DBMS abstraction layer. The idea is to concentrate all of the complexity of data handling into a single code base which serves that data to other code bases. It's not about building another ODBC or Pear library that tries to be DBMS agnostic. Within the abstraction layer you can and should leverage all of the power and features of your chosen DBMS as you can.

If all of your sql is only allowed in one code base which is then consumed by all your other applications via a formal api, then if you decide to switch from say, MySQL to SQLServer, you only have to change the one code base without worrying about all the consumers of that data. That's what we mean when we say it's easy, or in other words, you don't have to do a thorough audit of all your web applications when anything about your database changes.

As long as the parameters going into and out of the data abstraction layer remain the same, you can radically change just about anything inside and below that layer. You can do things like normalize a large table into a parent child relationship in real time with no downtime or maintenance window. Or you can decide to put those log files into a database without your log viewer web app knowing anything about it.

Of course, for some backend changes you might want to have one of your web sites do something different but the point is that you don't have to make all your changes to all your software and roll it out into production all at the same time. You can change the back-end and the abstraction layer to handle it, then when you're ready, start changing your web sites to use the new api methods that support the new features.

There is no "one way" of implementing a data abstraction layer. If all you do is php, then write it in php and have your php "clients" include and extend the data abstraction classes directly. Or write a thin php web service on top of the abstraction layer and have your mainline applications call that. Or write your data abstraction layer in java (for multi-threading) and use thrift to talk to it, which is supported by lots of different languages.

Just keep a clear separation between the sources of data and the scripts that want it by making a rule that no sql or file handlers can exist in any other code base except this one, and that this one code base can have no concept of sessions or html or json or javascript, and then you will have built a data abstraction layer.

So nothing has been limited or constrained. It's just a smart way of organizing the code that you would have to write anyway.