[Clubber]

I assuming you mean writing all the business logic in stored procs and functions. Every time I've seen this, it ended up horribly. I use the database for storage and data validation only. I write a middle tier for the business logic, and of course the front end layer.

I'm not saying it can't been done well, but it poses enough problems that are difficult to avoid, like calling an external web service inside a stored procedure, and the general mess of maintaining a bunch of chained stored procedures, functions.

It also guarantees vendor lock-in.

[spacemanmatt]

I should also mention, I found it common and well-received to use this pattern for sustaining development on an enterprise app. Some logic has to be in the database anyway.

[collyw]

In my experience, keep the logic in / close to the data model and the application code becomes very clean and easy. If you have a crap data model, then lots of implicit rules start appearing at the application level, bugs start to appear and no one knows exactly what the application should be doing, as all the rules are tied up in some crappy crufty code.

Like Linus said, bed programmers worry about the code, good programmers worry about the data and its relationships (or something to that effect).

[spacemanmatt]

That experience is why I propose pushing as much business logic down into the data layer as possible as a matter of implementing a rite-of-passage code. For organizations, this puts a premium on db programmers, but it also protects their data from less-skilled programmers.

[spacemanmatt]

What you describe is reasonable enterprise architecture. I'm responding to a fairly different question.