Re: RM's Canonical database
Date: Mon, 03 Jul 2006 20:11:45 GMT
Message-ID: <5Seqg.5764$pu3.130430_at_ursa-nb00s0.nbnet.nb.ca>
Marshall wrote:
>>The truth of the matter is we >>have several uniform and universal names for these 'rules' including the >>word 'rules' as well as the word 'constraints'.
>
> I have never been very clear on a taxonomy of these things. What
> *exactly* "business rules" are I'm not certain.
>
> If we are speaking of declarative integrity constraints written in
> FOL, it is clear what is being denoted.
>
> If we are speaking of procedural app server code that executes
> updates, it is clear what is being denoted.
>
> I don't have short, specific terms for either of these.
>
> Also, what about building abstractions inside the dbms
> that execute updates, a la stored procedures. Is that
> ever done? Good idea, or what? Theoretical foundations?
You mean like triggered procedures? Yes, that is done. Like most design
options, whether it is a good idea depends on a lot of factors. Do audit
trails have a theoretical foundation? I don't know. But one pretty much
has two choices for them: 1) use a product that preserves the entire log
and allows one to query the state of the database at any past moment and
all transactions or 2) use a triggered procedure to record the audited
facts.
> I am somewhat frustrated that my professional experience
First, let me say I do not think a theoretical understanding is
weak--quite the opposite. Second, I suggest Date's _Introduction to
Database Systems_ is probably the most comprehensive text with regard to
these issues. The classification of constraints has evolved over the
years, and I would say the evolution has more to do with aesthetics and
elegance than with theory.
> has never included any of the features of SQL outside
> of queries and updates, and only the most minimal of
> integrity constraints: primary and foreign keys. My
> understanding outside of this area remains weak
> and/or theoretical only.