Stored procedures or OR mappers?

Question

Which is better? Or use and OR mapper with SP\'s? If you have a system with SP\'s already, is an OR mapper worth it?

Answer 1

If you already have a data API that's exposed as sprocs, you'd need to justify a major architectural overhaul to go to ORM.

For a green-fields build, I'd evaluate several things:

1. If there's a dedicated DBA on the team, I'd lean to sprocs
2. If there's more than one application touching the same DB I'd lean to sprocs
3. If there's no possibility of database migration ever, I'd lean to sprocs
4. If I'm trying to implement MVCC in the DB, I'd lean to sprocs
5. If I'm deploying this as a product with potentially multiple backend dbs (MySql, MSSql, Oracle), I'd lean to ORM
6. If I'm on a tight deadline, I'd lean to ORM, since it's a faster way to create my domain model and keep it in sync with the data model (with appropriate tooling).
7. If I'm exposing the same domain model in multiple ways (web app, web service, RIA client), I'll lean to ORM as then data model is then hidden behind my ORM facade, making a robust domain model is more valuable to me.

I think performance is a bit of a red herring; hibernate seems to perform nearly as well or better than hand-coded SQL (due to it's caching tiers), and it's easy to write a bad query in your sproc either way.

The most important criteria are probably the team's skillset and long-term database portability needs.