Re: Thoughs after discussions at OSCON

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-advocacy(at)postgresql(dot)org
Subject: Re: Thoughs after discussions at OSCON
Date: 2005-08-15 17:57:10
Message-ID: 60acjjulqh.fsf@dba2.int.libertyrms.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy

ned(at)nedscape(dot)com (Ned Lilly) writes:
> Chris Travers wrote:
>
>> Personally I have never bought the "Put as much logic into your
>> database as possible." This can *easily* be taken way too far.
>> Review the discussions on pgsql-general about why sending email
>> from the database backend is a bad idea. Can you write a CRM
>> application server in PLPGSQL? Sure. But I am not sure it is a
>> good idea.....
>
> We've got a very powerful ERP system that has most of its
> transactional business logic in pl/pgsql, so I'll respectfully
> disagree with you here ;-) We think it makes a powerful showcase for
> what PostgreSQL can do with even commodity-level server hardware.

It seems to me to be a tough call exactly where to stop.

There is considerable *obvious* merit to adding in logic that resides
at the "declarative" level such as the case where constraints provide
somewhat self-documenting data validation.

It seems to me that adding additional such "predicates" comes at a
relatively low cognitive cost.

Foreign key constraints are commonly worthwhile, albeit being
something that has a slightly higher "cognitive cost" as well as
having some potentially negative performance implications. You
mightn't want to implement every FK that is theoretically possible to
implement.

Implementing APIs within the database falls, in my mind, into a more
ambiguous area.

There are numerous good things about making extensive use of pl/pgsql;
you cut down on round trips, and can keep the data validation in an
API that, by being in the DBMS, makes it accessible to ANY accessing
application regardless of what language the application may use.

But it adds an extra layer of logic, and figuring out what is running
where does introduce some "cognitive cost."

Furthermore, if there is a legitimate need for portability between
databases (e.g. - you have an important customer who REALLY wants
Oracle|DB2 support), the cost of using stored procedures efficiently
and quasi-portably goes way up.

For someone to argue that implementing most business logic inside the
DB isn't their favorite idea is something where there needs to be some
room for disagreement :-).
--
output = ("cbbrowne" "@" "ntlug.org")
http://www3.sympatico.ca/cbbrowne/emacs.html
"Few people can be happy unless they hate someother person, nation or
creed." -- Bertrand Russell

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Chris Browne 2005-08-15 17:58:51 Re: Thoughs after discussions at OSCON
Previous Message Chris Browne 2005-08-15 17:46:12 Re: Thoughs after discussions at OSCON