On 8/15/07, Steve Manes <[EMAIL PROTECTED]> 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... ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
