Re: PF File Definition questions...

["R. Bruce Hoffman, Jr." <rbruceh@xxxxxxx>]

The reason to key or not key a physical is a personal one more than anything
else.

The other reason to not key a physical file is that you are going to drop
(remove the logical members) of any access paths before large batch updating
to a physical.

Another reason would be that you are doing direct processing of the file and
can not risk having the records resequenced, but there are other ways to do
that. (Key by a sequence number)

One thing you should note, 1st normal form requires a physical file to have
a primary key, a unique field that unambiguously identifies every single
record in the file.

ANY access path that is built and has *IMMED maintenance is updated when the
underlying physical key field is updated. Also note that the seize is taken
on the logical to determine if the key has changed, even if there is no
update, it's just much shorter.

-----Original Message-----
From: Chuck Lewis <clewis@iquest.net>
To: MIDRANGE-L@midrange.com <MIDRANGE-L@midrange.com>
Date: Thursday, October 14, 1999 10:31 PM
Subject: PF File Definition questions...


>Hi Folks !
>
>Was wondering how folks define PF's when it comes to keyed or not.
>
>Is there something I'm missing when it comes to NOT having the "most
>common" field(s) in a PF defined in the PF a key field(s) ?
>
>Then handle the less obvious stuff in LF's ?
>
>One less access path...
>
>Why PF's with NO key fields ?
>
>Also, I was told YEARS ago (on the S/38) that you should try to keep the
>number of LF's over a PF to a minimum, say 3, 4 tops and let your
>program handle the level breaks, etc. to help system performance. Even
>on the AS/400 there has GOT to be some truth to that just due to the
>fact that there aren't a BUNCH of access paths that have to be rebuilt.
>I've seen some vendor packages with a hundred LF's over one PF !!!!
>
>Thanks !
>
>Chuck
>
>+---
>| This is the Midrange System Mailing List!
>| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
>| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
>| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner/operator:
david@midrange.com
>+---
>

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---