![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Jul. 6th, 2007 10:55 am(Cross-posted here from my technology blog: http:www.adigitalera.com)
So, I'm currently listening to the ORM Smackdown on .NET Rocks! Its actually very interesting, but I definitely have a pet peeve with the ORM advocates. One of the stronger arguments in terms of using ORM is that you become database independent; if you want to switch from MS SQL to Oracle or MySQL you don't necessarily have a problem doing this; the ORM layer takes care of the mapping. I suppose this is great, except for one thing: abstractions leak. Now you have this big ORM layer that maps between different databases. I guarantee there are db concepts that won't be in that model, possibly very nice database features. And, really, how often are you going along on a project when you suddenly decide that you'd like to invest huge amounts of money in changing your database?
Because, if you do, really your database access code will be the least of your problems. All of the sudden you need to roll-out new servers, deal with licensing, deal with migrating your current data, deal with training your db professionals in an entirely different architecture, and any one of the thousand problems that come with doing major architectural changes to your system.
In short; being database independent is nice, but its not really that important. More important is having a good idea what you want your basic architecture (at least in terms of web server & db server) before you go to production. Changing things later will be guaranteed to be harder.
So, I'm currently listening to the ORM Smackdown on .NET Rocks! Its actually very interesting, but I definitely have a pet peeve with the ORM advocates. One of the stronger arguments in terms of using ORM is that you become database independent; if you want to switch from MS SQL to Oracle or MySQL you don't necessarily have a problem doing this; the ORM layer takes care of the mapping. I suppose this is great, except for one thing: abstractions leak. Now you have this big ORM layer that maps between different databases. I guarantee there are db concepts that won't be in that model, possibly very nice database features. And, really, how often are you going along on a project when you suddenly decide that you'd like to invest huge amounts of money in changing your database?
Because, if you do, really your database access code will be the least of your problems. All of the sudden you need to roll-out new servers, deal with licensing, deal with migrating your current data, deal with training your db professionals in an entirely different architecture, and any one of the thousand problems that come with doing major architectural changes to your system.
In short; being database independent is nice, but its not really that important. More important is having a good idea what you want your basic architecture (at least in terms of web server & db server) before you go to production. Changing things later will be guaranteed to be harder.
