Zawodny: Database Abstraction Layers Must Die (at least for PHP)(jeremy.zawodny.com)
jeremy.zawodny.com
Zawodny: Database Abstraction Layers Must Die (at least for PHP)
http://jeremy.zawodny.com/blog/archives/002194.html
24 comments
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.
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?
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?
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.
Yeah, I think he was more railing against "abstraction layers" that try and make calls to the DB look no different than the native language data structures.
His library is akin to separating the 'M' from the 'C' in MVC. He is saying that people go to the trouble of using these DB abstraction layers so they can proceed with spagetti coding the model (persistence layer in his terms) and the controller (business logic layer in his terms) together.
I'm not sure how valid that argument is though. Anyone I know that bothers to use an abstraction layer also separates the model from the controller.
His library is akin to separating the 'M' from the 'C' in MVC. He is saying that people go to the trouble of using these DB abstraction layers so they can proceed with spagetti coding the model (persistence layer in his terms) and the controller (business logic layer in his terms) together.
I'm not sure how valid that argument is though. Anyone I know that bothers to use an abstraction layer also separates the model from the controller.
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.
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.
"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.
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.
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.
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 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...
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 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.
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.
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.
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.
But along this line - PHP started as a template language... and it should have remained a template language.
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.
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.
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.
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.
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.
I know this to be the case with Rails as well. I think his point about database portability has more to do with the data portability itself; obviously, if you switch databases, you presumably need to port all of your existing data to the new database system, including things like indexes, etc., and you may even have to do some new tuning work, since the new database system might have different ways of optimizing queries, etc. Now, admittedly, I haven't looked to see if there are conversion tools, but I wouldn't be surprised if there were things out there to ease a transition from one system to another. And in any event, so what if you DO have to do all of that...using a database abstraction layer will AT LEAST save you the time of having to go through your source and change a bunch of database system-specific calls.
Anyway, I just find his argument totally unconvincing.
Anyway, I just find his argument totally unconvincing.
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.
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.
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.
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.
Sure; but this is more of an argument against abstraction in general, vs. an argument against database abstraction in particular. If you use any kind of framework, since frameworks are made to be generally usable in many different situations with differing requirements, there's ALWAYS going to be stuff going on that you have no control over that you probably don't need for your project.
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
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
2004! This article is 5 years old, and it's a reply to an article written in 2002!
As long as they take the rest of PHP with them when they die, I'm all for it.
Yeah, put the SQL in the view - where it belongs. Long live Spaghetti PHP!
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.
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.