On 8/15/07, Steve Manes <smanes@magpie.com> wrote:
> I'm fairly hardcore about keeping as much business logic as I can in the
> database. In fact, I only do SELECTs from the application, and usually
> via Views. All inserts, updates and deletes are via procs. I'm a
> proponent of separating application code from presentation and
> application code from database code. And HTML from layout style, for
> that matter.
>
> In addition to the other reasons you've gotten:
> Another is because I want transactions to start and end in the database,
> not in external application code which might crash before a COMMIT.
Hmm, how do you handle this logically? Do your applications never
need to submit chunks of work at once? Or do you do something like
fill in a temporary table, and have a proc work from that?
> Another is because I'm a freelancer and generally hand off my
> applications to the client's tech department, which is often a junior
> level grasshopper who knows just enough SQL to be dangerous. Using
> stored procedures raises the bar on what they need to know about RDMBSes
> before they start hacking working code.
...although that helps explain "why" a bit more: if you're stuck with
people who can't use transactions properly, it makes sense to keep
them out of reach...
