Re: best place to enfore rules - Mailing list pgsql-general

From Frank D. Engel, Jr.
Subject Re: best place to enfore rules
Date
Msg-id C3FCEF6F-65A6-11D9-8A04-0050E410655F@fjrhome.net
Whole thread Raw
In response to best place to enfore rules  ("Rick Schumeyer" <rschumeyer@ieee.org>)
List pgsql-general
I would suggest doing both, really: have the client check, so that
options which are not available to the user appear "disabled" in the
first place, and have the server check as well, so that "fake" clients
(clients other than yours) attempting a transaction cannot perform
invalid operations in order to thwart policies and security.


The "real" security is on the server side, but the "nice" security
(more meaningful error messages, disabling of UI components not really
available, etc.) must be done on the client side.


On Jan 13, 2005, at 3:09 PM, Rick Schumeyer wrote:


<excerpt><fontfamily><param>Arial</param><x-tad-bigger>I’m new both to
databases and postgres, so forgive me if this is a stupid question.</x-tad-bigger></fontfamily>


<fontfamily><param>Arial</param><x-tad-bigger> </x-tad-bigger></fontfamily>


<fontfamily><param>Arial</param><x-tad-bigger>Where do people usually
enforce business rules?  In the client application or in the database?</x-tad-bigger></fontfamily>


<fontfamily><param>Arial</param><x-tad-bigger> </x-tad-bigger></fontfamily>


<fontfamily><param>Arial</param><x-tad-bigger>For example, I might
have a rule “don’t allow customers to enter an order if their account</x-tad-bigger></fontfamily>


<fontfamily><param>Arial</param><x-tad-bigger>is delinquent.”  I could
create rules, triggers, etc. to prevent an entry into the “order” table</x-tad-bigger></fontfamily>


<fontfamily><param>Arial</param><x-tad-bigger>given some condition in
the “account” table.  Or I could put the logic on the client side.</x-tad-bigger></fontfamily>


<fontfamily><param>Arial</param><x-tad-bigger> </x-tad-bigger></fontfamily>


<fontfamily><param>Arial</param><x-tad-bigger>I would think it would
be better to do this inside the database.  I’m not familiar with how</x-tad-bigger></fontfamily>


<fontfamily><param>Arial</param><x-tad-bigger>the client would know
what is happening.  I guess the client can tell if an SQL command</x-tad-bigger></fontfamily>


<fontfamily><param>Arial</param><x-tad-bigger>failed, but will the
client know why it failed?</x-tad-bigger></fontfamily>


<fontfamily><param>Arial</param><x-tad-bigger> </x-tad-bigger></fontfamily>


<fontfamily><param>Arial</param><x-tad-bigger> </x-tad-bigger></fontfamily>


</excerpt>-----------------------------------------------------------

Frank D. Engel, Jr.  <<fde101@fjrhome.net>


$ ln -s /usr/share/kjvbible /usr/manual

$ true | cat /usr/manual | grep "John 3:16"

John 3:16 For God so loved the world, that he gave his only begotten
Son, that whosoever believeth in him should not perish, but have
everlasting life.

$

I would suggest doing both, really: have the client check, so that
options which are not available to the user appear "disabled" in the
first place, and have the server check as well, so that "fake" clients
(clients other than yours) attempting a transaction cannot perform
invalid operations in order to thwart policies and security.

The "real" security is on the server side, but the "nice" security
(more meaningful error messages, disabling of UI components not really
available, etc.) must be done on the client side.

On Jan 13, 2005, at 3:09 PM, Rick Schumeyer wrote:

> I’m new both to databases and postgres, so forgive me if this is a
> stupid question.
>
>  
>
> Where do people usually enforce business rules?  In the client
> application or in the database?
>
>  
>
> For example, I might have a rule “don’t allow customers to enter an
> order if their account
>
> is delinquent.”  I could create rules, triggers, etc. to prevent an
> entry into the “order” table
>
> given some condition in the “account” table.  Or I could put the logic
> on the client side.
>
>  
>
> I would think it would be better to do this inside the database.  I’m
> not familiar with how
>
> the client would know what is happening.  I guess the client can tell
> if an SQL command
>
> failed, but will the client know why it failed?
>
>  
>
>  
>
-----------------------------------------------------------
Frank D. Engel, Jr.  <fde101@fjrhome.net>

$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten
Son, that whosoever believeth in him should not perish, but have
everlasting life.
$

Attachment

pgsql-general by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: Functions returning RECORD
Next
From: Peter Eisentraut
Date:
Subject: Re: pgpool