I totally agree. DB abstraction libraries buy you very little in terms of database portability. I use them in my projects, but only because their object-oriented APIs are nicer to work with than plain pgsql_/mysql_/etc functions.
I worked on at least 3 large projects where we went through a lot of trouble to make them work on multiple databases. All that effort was wasted as all of them ended up running on Postgres only. Unless you're absolutely sure that you're going to need support for multiple databases, my suggestion is that you use the technique from the end of the article: put all of your DB access code in separate classes so you can easily swap them with different ones should the need arise. Until then, save yourself some trouble and make your product work really well with one database engine.
Comments
I totally agree. DB abstraction libraries buy you very little in terms of database portability. I use them in my projects, but only because their object-oriented APIs are nicer to work with than plain pgsql_/mysql_/etc functions.
I worked on at least 3 large projects where we went through a lot of trouble to make them work on multiple databases. All that effort was wasted as all of them ended up running on Postgres only. Unless you're absolutely sure that you're going to need support for multiple databases, my suggestion is that you use the technique from the end of the article: put all of your DB access code in separate classes so you can easily swap them with different ones should the need arise. Until then, save yourself some trouble and make your product work really well with one database engine.