|
I always define a key on PF. Like AL says just
the obvious and easier to look up.
I do however have way more
than 3-4 LF per PF. This is mainly due to not only other sort criteria but also
for omit/select criteria which makes programs run faster at
night/eom.
At 02:59 PM 10/14/1999 +0100,
you wrote:
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) ?
Most
folks define PFs with keys, as this makes them easier to use. SQL
defines "tables" (PFs) without keys, and only defines
"views" (LFs) with keys. SQL is the industry standard for
the definition of database files, which IMHO is inferior to DDS.
IBM
is pushing us to use SQL because they are either stupid (do it like the rest
of the world, you dummies or go @#$% off) or cheap (same money, [by not
defining DDS interfaces to new stuff like BLOB/LOB support] make the stock
price go up, and when Lou quits, sell your stock and sell it
short).
Hopefully just before Lou quits, he will sell them AS/400
Division (because it is clearly not strategic [in his opinion], because this
will make the stock go up more. I hope that when Lou firesales the
AS/4D he calls us, because most likely everybody on this list would buy
stock, and after the AS/400 rules the world (from a technology perspective),
we would all have more money than Lou.
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 !!!!
I had a S/38 customer years
ago who did a *ALLOBJ backup on 6 tapes (6250), which I found to be highly
suspicious. When I migrated them to their AS/400, I told them to be
sure to specify ACCPTH(*YES), and they showed up with 30 tapes! Their
"order detail" physical file had 125 LFs on
it!
Al
+--------------------------------------------------+
| Please do not send private mail to this address. |
| Private mail should go to
barsa@ibm.net. |
+--------------------------------------------------+
Al Barsa, Jr. - Account for Midrange-L
Barsa Consulting, LLC.
400 > 390
Phone: 914-251-1234
Fax: 914-251-9406
http://www.taatool.com
|
midrange.com
