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