Anyway, I just find his argument totally unconvincing.
That's certainly one way to go, and it makes sense if your product is a Framework intended to be used by thousands of developers on thousands of projects, many of which will require that kind of portability. If, however, your product is a product, then maybe it's not so important.
But how many web apps require this? If caching can easily prevent the bulk of your database hits, then an ORM like Django is a great tool for the job, saves a large amount of work, and scales beautifully. This is especially important for the typically short dev cycle that Django targets.
He goes on saying "database abstraction layers" are bad but then, at the end says he uses a "library" that abstracts away database issues such as persistent connections, replication awareness and load balancing. How is that not a database abstraction layer?
DB Abstraction layer has helped me reuse the same libraries on different DB engines more than once.
I had one occurance when I needed to install my new webapp in a hurry (for demonstration purposes) and couldn't arrange for a database with the server administrator fast. Well... I just changed "mysql" to "sqlite" in my DB config, fixed a few problems with SQL CREATE statements and it worked.
On a side note I also agree with the "PHP is the best templating languge" idea. I just use a template class for it that has a similar API to Smarty.
So yes, I use abstraction layers in both cases. I guess that is more convenient because I do not work on any one web application for too long and I need to carry my libraries and knowledge painlessly from place to place. If I had only one application to build and support at one location... who knows, maybe I would even write php extensions for it in C.
I'm also kind of tired of programmers who complain and complain about others taking the easy way out, people don't program like they used to, etc.; the whole reason for having abstractions is to take some of the 'real' programming out of the equation and let you focus on the actual task you want to accomplish. It may not be the most efficient method of programming, but there are only so many hours in a day...
I don't think that's it, or if it is, it's not a very good reason. Using a templating system that's less than a full programming language keeps you from putting too much logic in your templates. Most of us prefer that logic and presentation be separated. PHP's HTML embedding tempts people to do the Wrong Thing in that regard.
If you write your app using an abstraction layer (or even a simple class wrapper), adding caching is almost trivial. If you are using the low level DB function calls it becomes a large task to cache any of your requests.
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.
this seem to me like "I'm paranoid about unknown code but I can't accept the truth SO I reinvent the wheel over and over again putting my code in my library and I say everyone this is cool cause it's faster and performance and bla bla blah"
the truth: abstraction -> helps think about the logic that matters in your program library -> helps not to reinvent the wheel and use code tested by everyone
his logic: abstraction -> ZOMG unknown stuff HEEELP, let's think about every algorithm in my program from scratch and let's justify this to me by saying I'm saving 3-4 intermediate function calls
Database abstraction, like many other things, serves a purpose under the right conditions (when flexibility and portability are needed to serve customers). Get over it.
