Re: Constraints, anyone? (PRIVATE REPLY)

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.