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
