Submitted by Arjen Lentz (not verified) on Fri, 11/16/2007 - 00:37.
The portability argument is often used - both in terms of SQL, and with database abstraction layers. There are sensible arguments for it, like having customers that use different database brands. But except for that, it's really a bad idea.
It does not scale. You're building in overhead, and an app built on a specific db is not just a matter of the SQL. Some schema choices, all the way to hardware choices, are inevitably geared towards that database.
So, migrating to another db later, apart from being time-costly and headache-painful, will not be optimal given the already existent underlying infrastructure. Having the portability layer may just makes it work, but it sure doesn't make it fast.
Chances are the migrated situation will be slower. If it's faster, then the original design infrastructure was apparently not optimal for the first db. It happens (usually gets highly publicised ;-) but it often merely indicates familiarity of the designers with a particular db, not the fundamental suitability of the other dbs they tried.
The portability argument is
The portability argument is often used - both in terms of SQL, and with database abstraction layers. There are sensible arguments for it, like having customers that use different database brands. But except for that, it's really a bad idea.
It does not scale. You're building in overhead, and an app built on a specific db is not just a matter of the SQL. Some schema choices, all the way to hardware choices, are inevitably geared towards that database.
So, migrating to another db later, apart from being time-costly and headache-painful, will not be optimal given the already existent underlying infrastructure. Having the portability layer may just makes it work, but it sure doesn't make it fast.
Chances are the migrated situation will be slower. If it's faster, then the original design infrastructure was apparently not optimal for the first db. It happens (usually gets highly publicised ;-) but it often merely indicates familiarity of the designers with a particular db, not the fundamental suitability of the other dbs they tried.