Zawodny: Database Abstraction Layers Must Die (at least for PHP)
jeremy.zawodny.com
Zawodny: Database Abstraction Layers Must Die (at least for PHP)
1–10 of 25 posts
Re: Zawodny: Database Abstraction Layers Must Die (at least for PHP)
#2I 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.
Re: Zawodny: Database Abstraction Layers Must Die (at least for PHP)
#3Based 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.
Re: Zawodny: Database Abstraction Layers Must Die (at least for PHP)
#4I 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.
Re: Zawodny: Database Abstraction Layers Must Die (at least for PHP)
#5He 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
Re: Zawodny: Database Abstraction Layers Must Die (at least for PHP)
#6I 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?
Re: Zawodny: Database Abstraction Layers Must Die (at least for PHP)
#7This 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.
Re: Zawodny: Database Abstraction Layers Must Die (at least for PHP)
#8Database 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.
Re: Zawodny: Database Abstraction Layers Must Die (at least for PHP)
#9It'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.
Re: Zawodny: Database Abstraction Layers Must Die (at least for PHP)
#10I 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?
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.