Beware of men preaching of false hope.
Take, for example, the way some folks feel like they need a database abstraction layer in their applications. Rasmus has long argued against them, and I've agreed with his reasoning and conclusion. (Because it's correct!)
I was reminded of this when I recently read "rant, by request...", in which the author argues against the Smarty PHP template system. Why? Because PHP is itself a templating system. Adding another layer increases complexity, degrades performance, and generally doesn't really improve things.
So why do folks do it? Because PHP is also a programming language and they feel the need to "dumb it down" or insulate themselves (or others) from the "complexity" of PHP.
In that same article, I find myself strongly disagreeing with something else the author says:
Pick any book on PHP from a shelf in your local bookstore, and look how result rows from a MySQL database are printed. (MySQL is of course the DBMS used in those books, which should already give you a clue about how bad the book is.) The mysql_-functions are used all over the place in the presentation layer.
So, only bad books discuss MySQL in their examples? Let's look past that obvious bashing, and continue...
Here, in these forums, we have learned people to not use those mysql_-functions directly, but use a database abstraction layer instead. This makes coding simpler (no need to know all those functions for the various DBMS's) and when they decide to use another DBMS instead of MySQL (and they undoubtedly will at some point), the conversion will be painless.
The fact that he generally pisses on MySQL isn't what bugs me, though it doesn't help. What bothers me is the double-standard. He's advocating "raw" PHP instead of more "abstract" templating languages because they're bigger, slower, more complicated. But when it comes to the database side of things, he's suddenly arguing for the bigger, fatter, slower abstractions again?
This makes no sense for several reasons. Let's look at them.
The Portability Fallacy
The author uses an argument I hear all the time: If you use a good abstraction layer, it'll be easy to move from $this_database to $other_database down the road.
That's bullshit. It's never easy.
In any non-trivial database backed application, nobody thinks of switching databases as an easy matter. Thinking that "the conversion will be painless" is a fantasy.
Good engineers try to select the best tools for the job and then do everything they can to take advantage of their tool's unique and most powerful features. In the database world, that means specific hints, indexing, data types, and even table structure decisions. If you truly limit yourself to the subset of features that is common across all major RDBMSes, you're doing yourself and your clients a huge disservice.
That's no different from saying "I'm doing to limit myself to the subset of PHP that's the same in Perl and C, because I might want to switch languages one day and 'painlessly' port my code."
That just doesn't happen.
The cost of switching databases after an application is developed and deployed is quite high. You have possible schema and index changes, syntax changes, optimization and tuning work to re-do, hints to adjust or remove, and so on. Changing mysql_foo() to oracle_foo() is really the least of your problems. You're gonna touch most, if not all, of your SQL--or you'll at least need to verify it.
That doesn't sound "painless" to me.
Good Programming vs. "Neutral" APIs
The author is also clearly unhappy with the alternative, having mysql_foo() and mysql_bar() functions all over the application. Well, I may be nuts here, but I never have that problem. I use a revolutionary new programming technique. Instead of littering my code with those calls, I put my core data access layer into a library--a separate piece of reusable code that I can include in various parts of my application and... reuse!
That means if I ever decide to make major changes to the way my application interacts with the database (persistent connections, replication awareness, load balancing, different error handling), I'm able to do so without searching every damned file in my code base for mysql_* functions that I need to tweak.
I never thought this was rocket science, but apparently it has eluded him. Somehow he manages to see the benefit of separating presentation from logic, but never considered separating the data access layer from the data processing layer.
Some things never cease to amaze me--and make me very sad at the same time.
Posted by jzawodn at July 08, 2004 09:35 AM