Re: Big Picture - Mailing list pgsql-novice

> Hi,
>  I think the definitions you describe below for application vs. business
> logic are maybe not quite rigourous enough for me to try and use in the
> workplace. But I am a database guy, I confess I like the idea of rules in
> the db. However there are always trade-offs.
>
>   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).
I'm not really sure what your're saying here.  But on reason for putting
business logic rules in the database is that it ensures that all
applications do the same thing.  For example, suppose you have two entities,
and wish to assign them together.  This may entail putting entries in
assignment tables, setting fields to initialise the start of the
relationship etc.  Putting this business logic in the database and only
providing an assign_a_to_b function (rather than direct insert access on the
tables) ensures that all applications correctly assign the two things.  It's
usually more efficient too if multiple tables are affected.

> Also certain rules will tend to have high liklihood of change over the
> lifetime of an enterprise, and certain rules are extremely unlikely to
ever
> change.  That is another criteria I use for the decision.  I do not like
the
> idea of having to change the most critical code in the enterprise any more
> than is absolutely neccesary.  Ask the business people, domain experts, or
> stake-holders- "will this rule ever change?" and "what is the likelihood
> that the rule will ever change?" The answers to those questions would
> provide clues where the code should live. If it is likely to change, I
would
> think it should not be in the DB...
Actually, I would stored these 'configurable' rules in the database, but
rather than hardcode the whole rule into a function, stored the 'variable'
components in a table.  But of course that presumes that you know what the
future change will be..

Mark