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

Stored procedures are better, in my view, because they can have an independent security configuration from the underlying tables.

This means you can allow specific operations without out allowing writes/reads to specific tables. It also limits the damage that people can do if they discover a SQL injection exploit.

Answer 2

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.

Answer 3

I like ORM's because you don't have to reinvent the wheel. That being said, it completely depends on your application needs, development style and that of the team.

This question has already been covered Why is parameterized SQL generated by NHibernate just as fast as a stored procedure?

Answer 4

There is nothing good to be said about stored procedures. There were a necessity 10 years ago but every single benefit of using sprocs is no longer valid. The two most common arguments are regarding security and performance. The "sending stuff over the wire" crap doesn't hold either, I can certainly create a query dynamically to do everything on the server too. One thing the sproc proponents won't tell you is that it makes updates impossible if you are using column conflict resolution on a merge publication. Only DBAs who think they are the database overlord insist on sprocs because it makes their job look more impressive than it really is.

Answer 5

Use stored procedures where you have identified a performance bottleneck. if you haven't identified a bottleneck, what are you doing with premature optimisation?
Use stored procedures where you are concerned about security access to a particular table.
Use stored procs when you have a SQL wizard who is prepared to sit and write complex queries that join together loads of tables in a legacy database- to do the things that are hard in an OR mapper.

Use the OR mapper for the other (at least) 80% of your database: where the selects and updates are so routine as to make access through stored procedures alone a pointless exercise in manual coding, and where updates are so infrequent that there is no performance cost. Use an OR mapper to automate the easy stuff.

Most OR mappers can talk to stored procs for the rest.

You should not use stored procs assuming that they're faster than a sql statement in a string, this is not necessarily the case in the last few versions of MS SQL server.

You do not need to use stored procs to thwart SQL injection attacks, there are other ways to do make sure that your query parameters are strongly typed and not just string-concatenated.

You don't need to use an OR mapper to get a POCO domain model, but it does help.

Answer 6

@ Kent Fredrick

My personal opinion of OR Mappers is their existence highlights a design flaw in the popular structure of databases"

I think you're talking about the difference between the relational model and object-oriented model. This is actually why we need ORMs, but the implementations of these models were done on purpose - it is not a design flow - it is just how things turned out to be historically.