Re: When to choose putting logic into PL/pgSQL and when to use an app server

On 15/03/12, Lew (noone(at)lewscanon(dot)com) wrote:
> Gavin Flower wrote:
> >Rory Campbell-Lange wrote:
> >>Frank Lanitz wrote:
> >>> I started to get into PL/pgSQL a bit as I'm started to work at an
> >>> application where I might can make usage of it. But I'm not sure even
> >>> those I read a bunch of documentation where is it useful to put logic
> >>> into database server and when I shall do the computing inside an
> >>> application layer... Does anyone of you have some kind of rule of a
> >>> thumb about that?
> >
> > So I suggest that you have a look at middleware, even if you decide
> > not to use it.
>
> +1 to that.
>
> I use the rule of thumb that if it's strictly about data, e.g.,
> enforcing consistency between tables, it can be a stored procedure.
> If it's about application logic, it goes in middleware.

...

> Database and business logic have different domains of discourse. If
> they're crossing over to each other, except in ORM mapping code,
> it's a problem.

I very much agree with Frank and Lew's points. Certainly for someone
starting out doing (what I presume is) web application programming, one
is likely to be able to get much more done far more quickly using a
middleware framework such as Rails or Django than hand-coding the data
management aspects in the database and (presumably) rolling your own
middleware.

However I strongly believe that ORMs are bad for databases and in
particular make terrible use of the the relational possibilities of a
capable database system.

I like Lew's aphorisms about data. Lew: do you agree that performing
complex queries though stored procedures can be beneficial?

Rory