Re: Rules, Triggers something more challenging

From: Bruno Wolff III <bruno(at)wolff(dot)to>
To: Tamir Halperin <tamir(at)brobus(dot)net>
Cc: Peter Csaba <cpeter(at)webnova(dot)ro>, pgsql-general(at)postgresql(dot)org
Subject: Re: Rules, Triggers something more challenging
Date: 2003-04-03 20:40:42
Message-ID: 20030403204042.GA30860@wolff.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Apr 03, 2003 at 12:52:10 -0500,
Tamir Halperin <tamir(at)brobus(dot)net> wrote:
> I'd like to make a suggestion, Peter:
>
> You may very well find a way to contstrain inserts using pgsql according to your business rules, but I observe that you're beginning to develop a dependency on the data layer for your business logic.
>
> The reason you may not want to rely on db componentry (rules, triggers, etc...) to implement this type of business logic is because at some point in the future your business logic may change and then you're required to heavily modify your database when it may not be a problem with the data.

On the other hand implementing security in the application doesn't work
if the application runs on the user's machine. For example Peoplesoft's
security for version 7.x is totally broken if you let people run two
tier (which you have to to let people do some things). The app eventually
connects to the data base with full update access to all tables and relies
on the user not tampering with the app.

If the app runs on a secure machine then implementing security on the
app server is reasonable (at least under some circumstances).

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Mike Mascari 2003-04-03 20:41:06 Re: SAPdb vs. Postgresql
Previous Message Tom Lane 2003-04-03 20:36:03 Re: 'DROP INDEX' kills stored rpocedures