
Zawodny: Database Abstraction Layers Must Die (at least for PHP) - Shakescode
http://jeremy.zawodny.com/blog/archives/002194.html
======
Davertron
I think this is just ridiculous. I'm not necessarily gung-ho about using
database abstraction layers myself, but the author only argues against it on
the basis of one of the benefits of using an abstraction layer. On top of
that, he then admits that he uses a database abstraction layer himself, albeit
a seemingly thin one.

~~~
smokinn
Yeah, I couldn't understand that either.

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?

~~~
nimbix
The way I understand it the phrase "abstraction layer" is usually used to
refer to the layer between your SQL and the database and is supposed to allow
you to run the same SQL using multiple database engines (at least in theory).
While the author's DIY library abstracts the database, I would say its main
purpose is isolation, not abstraction. This makes it easier to port apps to
new DB engines because it's not that hard to replace an instance of a class
with mysql specific code with an instance of a class containing postgres
specific code.

~~~
smokinn
I suppose. But abstraction layers give you so much more than that. A good
counter-example for why you should use one is simply prepared queries. Doing
stuff like:

mysql_query("SELECT something FROM table WHERE that='" .
mysql_real_escape($var) . "'"); is just terribly ugly and annoying, especially
if the query gets complex.

I've never put any faith in the whole database portability claim for exactly
the reason he points out. Any even moderately complex app is going to leverage
database-specific performance enhancements that can't be abstracted away.

~~~
Davertron
"Any even moderately complex app is going to leverage database-specific
performance enhancements that can't be abstracted away."

I'm not sure I totally agree with you here; I run what I would consider to be
a "moderately complex" app (basically an e-commerce site) using PHP and MySQL
with no data abstraction layer (if I had my choice, I WOULD use one...). We
don't leverage any database-specific performance enhancements directly via our
queries (we do use indexes and the like on particular tables to help speed up
certain queries though), because MySQL is generally better at it than I would
be. Granted, I'm no DBA, and I can see how some people out there really CAN
tweak their own queries to be more efficient than the database system
optimization might be. But in general, in the ideal situation, I'd much rather
have clean, portable code, and once in awhile have to avoid the abstraction
layer (any good database abstraction layer will allow you to write your own
SQL if you wish, and if it doesn't, there's nothing stopping you from not
using the abstraction layer for that particular query) then to not use the
abstraction layer at all.

I guess my point is, in general, you don't start out optimizing; you optimize
where you need to optimize when you need to, and the benefits of using an
abstraction layer for 90% of the stuff I would do far outweigh any possible
downsides.

------
emilis_info
Based on my experience, I do not agree with the author.

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.

~~~
profquail
I agree with you 100%. Smarty (or similar templating engines) can make it much
faster to get a website up and running; as for the speed complaint, Smarty
compiles it's templates to PHP the first time you run them, so there's really
not much difference after that.

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...

------
nimbix
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.

------
Zak
_So why do folks [make templating systems like Smarty]? 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._

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.

~~~
rjurney
But along this line - PHP started as a template language... and it should have
remained a template language.

------
abyssknight
This is bull. I've used straight mysql_* calls, PEAR::MDB2, as well as a
custom rolled DB abstraction class before. Personally, I prefered MDB2 because
of the portability and ability to do prepared statements (which wasn't
available in our version of MySQL and PHP at the time). Changing the few bits
of SQL that need changed is far easier than retooling an entire application
(i.e. code changes). The other added value is that the developers don't have
to relearn the DB functions.

------
bcl
Database portability isn't the only reason to use a DB abstraction layer. They
provide a way to better integrate the data from the DB with your language's
data types and development model. Not to mention making it easier to plug in
caching like memcached.

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.

~~~
prodigal_erik
Adding caching should be a large task, because cache coherence is hard. If you
do it the trivial way you are almost certainly not figuring out which cache
entries need to be invalidated during an update, and getting wrong answers.

------
teilo
I don't know much about PHP abstration layers, but Django's ORM makes an app
pretty damn portable from DB to DB. I know, without a doubt, that I could roll
out my CMS/blog/documentDB in a heart beat to MySQL, Postgres, Oracle, and
SQLite with nothing but a change to the settings file. I have to think that
Django is by no means unique in this regard, and that PHP has the equivalent.

~~~
jasonkester
Django pulls this off by being specifically designed to do it. There's a ton
of code back there running for every query you execute, adding a tiny bit of
overhead to everything you do, just on the off chance that maybe one day you
might want to migrate to another DB.

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.

~~~
teilo
For DB intensive apps querying a wide distribution of changing data, say, an
accounting or project management system, you are absolutely right. An heavily-
abstracted ORM is the wrong tool for the task.

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.

------
elv
He starts saying DB abstraction layers are useless and he seem to conclude
saying every abstraction and every library not written by you is pointless

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

------
IsaacL
2004! This article is 5 years old, and it's a reply to an article written in
2002!

------
technomancy
As long as they take the rest of PHP with them when they die, I'm all for it.

------
rjurney
Yeah, put the SQL in the view - where it belongs. Long live Spaghetti PHP!

------
edw519
It's tough to take anyone seriously who calls something he disagrees with
"bullshit".

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.

