Re: Calling DB/400 gurus - where to put DB keys physical or logical?

This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
This debate again?

I say key your physical files.  Most software vendors do not support
referential integrity, they 'roll their own' and then assume that all file
updates are done only via their 5250 programs.  I have numerous duplicate
keys in the BPCS item master for example.  In fact, their IIML01 doesn't
care if the keys are duplicates.

Even if you do set up UNIQUE in your logical files, there are times when
the logical is not 'active' that duplicates can be inserted.  I proved
this the last time this discussion came up.

Used to be a concern, way back in the dark ages, that a file with a key
could get corrupted or some such thing but there hasn't been any real life
examples given since humans started walking upright.  (No offense meant to
creationists.)

Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin




"Villa, Mark" <mvilla@briggsplumbing.com>
Sent by: midrange-l-admin@midrange.com
10/16/2002 08:32 AM
Please respond to midrange-l


        To:     <midrange-l@midrange.com>
        cc:
        Fax to:
        Subject:        Calling DB/400 gurus - where to put DB keys physical or 
logical?


I have always designed physical files with keys (unique ones).
Now my eyes have been opened to a world of PF's that have no key that
are always accessed with keyed logicals. To my surprise, this seems to
be method of choice for some very common large scale software providers.

I am thinking this matters greatly for future proofing, performance, and
possible integration with other databases.

My question: Is one way better than the other and what are the reasons?


Mark Villa in Charleston SC
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.