Comments on: Moving past stored procedures

By: Jimmy Bogard

Jimmy Bogard — Tue, 04 Mar 2008 13:03:51 +0000

@Lars

Ah ok, I see now. Our solutions are generally database-agnostic, and we never use DB-specific features. I’ve only needed to “dip the toe in the waters” when very specific scenarios pop up (i.e., hierarchical queries, etc.)

I’d be very curious to see the differences between Oracle-centric applications and one centered around DDD principles…

By: Lars Pohlmann

Lars Pohlmann — Tue, 04 Mar 2008 10:14:00 +0000

@bogardj: No, I’m not a DBA, I’m a pl/sql-Developer. And though I would have chosen another architecture, if I would have been the one to make the decision a few years ago, I can say that Oracle gives you some powerful tools to handle the business-logic within the database. And looking back, I’m glad this decision was made within my company. I wouldn’t try this with MySQL. Can’t say anything about SQL-Server as I don’t have any experience with it.

By: Jimmy Bogard

Jimmy Bogard — Mon, 03 Mar 2008 15:04:30 +0000

@Lars

Just curious, is an oracle-developer an Oracle DBA? This is the same approach on any DB I use, whether it’s Oracle, SQL Server, MySQL, etc. I don’t think there’s anything MS-centric about it, is there?

By: Lars Pohlmann

Lars Pohlmann — Mon, 03 Mar 2008 13:30:21 +0000

To put my comment into perspective:

I am an oracle-developer. You are talking about microsoft-centric development. I don’t know how SQL-Server handles stored-procs, but I heard, that it’s much worse than oracle.

By: Jeff Tucker

Jeff Tucker — Tue, 26 Feb 2008 22:58:24 +0000

@Chad: I agree, it doesn’t require a stored proc, but my point was more that business logic doesn’t belong in sql, however things that databases do well don’t belong in your business domain code.

As for stored procs themselves, I find that in the particular application that I am currently writing that my preference for managing database interaction is through stored procedures (so far) although I agree with your point about performance. I’ve found this to be true in several instances in the past as well. I’m working on a blog post that goes into a lot more detail about why I feel this way. I promise that I’ll post it this week.

By: Chad Myers

Chad Myers — Tue, 26 Feb 2008 20:44:04 +0000

@Jeff: But how does any of that require a stored procedure?

You can do sorting and joining without sprocs and get the same performance.

By: Jeff Tucker

Jeff Tucker — Tue, 26 Feb 2008 18:48:43 +0000

Jeff’s second law of programming: Let the database do the work.

Databases are way better than we will EVER be at things like sorting and joining. Those things are not business logic. I think that the business layer should drive how the db does those things, so if I want a set of records I tell the stored procedure how to sort them through parameters. This allows the database to do what it does best but still gives me control over what the database actually does in terms of business logic.

By: Jimmy Bogard

Jimmy Bogard — Fri, 22 Feb 2008 15:10:23 +0000

@Steve

Then I always fall back to what’s most maintainable. Oren writes:

http://www.ayende.com/Blog/archive/7698.aspx

http://www.ayende.com/Blog/archive/2006/04/05/7692.aspx

By: Steve Campbell

Steve Campbell — Fri, 22 Feb 2008 14:43:25 +0000

Perhaps the stored procedure conversation has come full circle now that we are talking so much more about “services”. After all, a set of stored procedures is simply a service layer on top of your data. So the question becomes “do you want to program your service layer in SQL, or in “.