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