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:
<x-tad-bigger>I’m new both to databases and postgres, so forgive me if this is a stupid question.</x-tad-bigger>-----------------------------------------------------------
<x-tad-bigger> </x-tad-bigger>
<x-tad-bigger>Where do people usually enforce business rules? In the client application or in the database?</x-tad-bigger>
<x-tad-bigger> </x-tad-bigger>
<x-tad-bigger>For example, I might have a rule “don’t allow customers to enter an order if their account</x-tad-bigger>
<x-tad-bigger>is delinquent.” I could create rules, triggers, etc. to prevent an entry into the “order” table</x-tad-bigger>
<x-tad-bigger>given some condition in the “account” table. Or I could put the logic on the client side.</x-tad-bigger>
<x-tad-bigger> </x-tad-bigger>
<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>
<x-tad-bigger>the client would know what is happening. I guess the client can tell if an SQL command</x-tad-bigger>
<x-tad-bigger>failed, but will the client know why it failed?</x-tad-bigger>
<x-tad-bigger> </x-tad-bigger>
<x-tad-bigger> </x-tad-bigger>
Frank D. Engel, Jr. <fde101@xxxxxxxxxxx>
$ 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:
PGP.sig
Description: This is a digitally signed message part
