Re: PG rules! (RULES being the word ;->) - Mailing list pgsql-general

From Janning Vygen
Subject Re: PG rules! (RULES being the word ;->)
Date
Msg-id 01071910340400.18488@janning
Whole thread Raw
In response to Re: PG rules! (RULES being the word ;->)  (Jason Earl <jdearl@yahoo.com>)
List pgsql-general
Am Mittwoch, 18. Juli 2001 21:02 schrieb Jason Earl:
> At the very least you should use the SQL 92 features
> that PostgreSQL has.  [...]

ok, i can agree to this.

> Besides, eventually your users are going to want to
> circumvent your middleware for one reason or another.
> PostgreSQL's constraints and referential integrity
> makes this sort of access safe.

but it is only safe if you put ALL businnes logic inside postgresql.
if you dont you should never access your databse via pgaccess or psql.

> Because of this once PostgreSQL gains the ability to return
> result sets from functions I will probably move *more*
> of my applications functionality directly into
> PostgreSQL.  That way I could use this logic not only
> from my primary application, but also from psql,
> one-off Python scripts, MS Access front-ends, etc.

So you split your business logic. I cant believe that this is easy to
achieve. I guess the main reason for putting businnes logic into the
database is performance!? Like if you have 1.000.000 persons and you
want to calculate the persons average age, you can instanciate all
person objects and calculate it OR just ask postgresql which will do
it much faster i guess.

So my conclusion to this topic is to put business logic into
postgresql when you benefit from it because of performance or because
of data integrity. On the other hand it is very difficult or mostly
impossible to put all businnes logic inside postgresql.

janning

pgsql-general by date:

Previous
From: Ben-Nes Michael
Date:
Subject: two constrains for one column
Next
From: "Dr. Evil"
Date:
Subject: Re: two constrains for one column