Re: Constraints, anyone? (PRIVATE REPLY)

[Luis Rodriguez <luisro58@xxxxxxxxx>]

Mark,

Not quite private or off-list... Nevertheless, I appreciate the info. I have
given DB2 seminars and always explain, as one of the advantages of using
SQL, the ability to express business rules in a clear and concise way. I
have found may programmers who are wonderful coders, but forget (or don't
know) everything about business.

Thanks again (and sorry about intruding).

Regards,

Luis Rodriguez
IBM Certified Systems Expert — eServer i5 iSeries


On Tue, Dec 8, 2009 at 8:39 PM, Mark S. Waterbury
<mark.s.waterbury@xxxxxxx>wrote:

> Hi, James:
> *    >>>---> private reply off-list <---<<<*
>
> I am not sure I follow your hypothetical example...
>
> May I suggest or recommend the following book:
>
>    *WHAT, Not HOW* - /The Business Rules Approach to Application
> Development/
>    by C. J. Date
>    Copyright (c) 2000 by Addison-Wesley
>    ISBN 0-201-70850-7
>
> You can find it here:
>
>
> http://www.abebooks.com/servlet/SearchResults?an=C+J+Date&sts=t&tn=What+Not+How&x=60&y=12
>
> This book gives examples of using SQL constraints and triggers to
> enforce "Business Rules" thus making the database (and applications
> built on top of the database) more declarative (and thus
> non-procedural), so requiring less code (in a 3GL or 4GL sense).
>
> All the best for the upcoming holiday season.
>
> Cheers,
>
> Mark S. Waterbury
>
>  > James H. H. Lampert wrote:
> > I've been reading the stuff you've referred me to, and I was delighted
> > to find that constraints go back at least to V4R2, which is further back
> > than we have any need for them to go.
> >
> > The subject of referential constraints brought a question to my mind,
> > something that may push the limits of what's possible, or it may exceed
> > those limits:
> >
> > (And keep in mind that I am NOT using the SQL sense of the word "table"
> > here!)
> >
> > Suppose I have a "reference table" file, FOOREF, that is keyed:
> >     PRITBLNUM   (primary table number)
> >     PRITBLENT   (primary table entry)
> >     SECTBLNUM   (secondary table number)
> >     SECTBLENT   (secondary table entry)
> >
> > containing a number of reference tables, some of which contain
> > second-level reference tables. For example, "Address types" would be
> > table "ADT", and "mailing address" would be entry "M" of table "ADT."
> >
> > Now suppose we have an address file, FOOADDR, with an "Address type"
> > field in it, which should contain a valid address type listed in the ADT
> > table of FOOREF.
> >
> > A referential constraint that would enforce a requirement that the
> > "Address type" value match a value in Table ADT of FOOREF would
> > obviously have to hold PRITBLNUM constant, match it to PRITBLENT
> > (despite the two fields being of different lengths), and treat SECTBLNUM
> > and SECTBLENT as "don't care" terms.
> >
> > Can that be done as a constraint?
> >
> > --
> > JHHL
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.