Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zawodny: Database Abstraction Layers Must Die (at least for PHP)

jeremy.zawodny.com

Post reply on HN
Print view View original

21–25 of 25 posts

Re: Zawodny: Database Abstraction Layers Must Die (at least for PHP)

#21

Post by Davertron »

smokinn wrote: post #17
nimbix wrote: post #10

Earlier quoted context omitted.

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 h…

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 poi…

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

Re: Zawodny: Database Abstraction Layers Must Die (at least for PHP)

#23

Post by teilo »

jasonkester wrote: post #13
teilo wrote: post #11

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.

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 project…

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.

Re: Zawodny: Database Abstraction Layers Must Die (at least for PHP)

#24

Post by prodigal_erik »

bcl wrote: post #8

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 call…

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.
Post reply on HN