Re: Big Picture

Ken,

> >   My general thinking is that one fundamental concept of RDBMS is
> data
> > _independance_ from applications (if I understand Dr. Codd
> correctly).
> This
> > faciliates the _same_ data to be used effectively and safely by
> many
> > different applications over the lifetime of the enterprise.  So if
> > additional code in the database reduces the effectiveness with
> which data
> > can be shared among different applications in the enterprise, at
> that
> point
> > I would advocate for that code to be somewhere else (assuming that
> code
> > doesn't risk "nonsense" data).

But it does risk "nonsense" data.   Look,in an ideal application, you
would have:

layer 1: SQL-DDL: tables, data repository
layer 2: Views, Triggers, Rules and Constraints:  data integrity rules
    and data abstraction
layer 3: Perl, Java, CORBA, whatever: data access and data security
    rules
layer 4: Perl, Java, CORBA, whatever: business rules and logic
layer 5: Perl, Java, CORBA, whatever: application logic and flow
    control and user rights
layer 6: HTTP + Perl/PHP or Java or QT or whatever:  User interface
    components.

Which is real great if you're working with a $250,000 budget.  However,
most of my applications run about $9,000 and look more like:

layer 1: SQL-DDL: Data repository. tables
layer 2: Views, Triggers, Constraints, PL/pgSQL procedures:  data
     security, business rules & logic, data integrity rules
layer 3: HTTP + PHP: user interface components, flow control, user
     rights.

For the above 3-layer "simple" application, putting the business rules
in PostgreSQL procedures, triggers, and rules makes a *lot* more sense
than putting them in the PHP.   Yes?

-Josh Berkus