[spacemanmatt]

Learn enough sql to write an application entirely in the db, except presentation layer, of course. Use OO concepts to hide data, provide accessors, etc. Write a wrapper library for accessors in your front end language of choice (CLI, Web, GUI, whatever).

You won't often see a big project structured this way, but it is very effective for a first hand experience of data driven design.

[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.

[collyw]

Judging by the last couple of applications I have inherited, most people should be doing this (but are not). The database is usually fast and should be doing a lot of the heavy lifting.

[spacemanmatt]

I found a significant disparity between the front-end application developers and the db-focused team I worked on, doing sustaining development. Basically, we were essentially out of IOPS so there was not any room for a bad query in production. Our db-team strategy was to provide safe APIs in SQL that paved a happy path for our front-end consumers. It was very successful.