RE: the idea of unique primary keys to be a solution thathasoutlived its usefulness?

[rob@xxxxxxxxx]

Not having unique keys on the physical, but only on the logical.  THAT, is 
a technique that I feel has outlived it's usefulness.

I think, originally, this was done on the S/38 or early versions of OS/400 
because of some obscure data corruption issue.  It just doesn't apply 
anymore.

If you do NOT put them on the physical you cannot add a referential 
constraint to this physical to another physical.  For example if I have a 
PF called CUSTMAST and a logical with CUSTMASTL1 and the unique key is 
only in CUSTMASTL1 then I cannot do a ADDPFCST on my order file to make 
sure that the customer number is on file.

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




"Rick DuVall" <R_C_DuVall@xxxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
11/17/2003 04:20 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: the idea of unique primary keys to be a solution    thathasoutlived 
its usefulness?






Hi Booth,

                 I seldom use keys on the physical myself, though I often 
have logicals with
unique.  In regard to your address issue...

EaDetail : Entity Address Detail...
Field                                    Len  Dec  Type  Text
EAENCLS                  10        A    Entity's Class
EAENTYP                  10        A    Entity's Type
EAENTID                  10        A    Entity's ID
EAENTATYP      10        A    Entity's Address Type
EAATTN                   40        A    Entity Attention
EAADDRNAM     40        A    Entity Name
EAADDRL1                 40        A    Entity Address Line  1
EAADDRL2                  40        A    Entity Address Line 2
EACITY                   30        A    Entity City
EASTATE                    2        A    Entity State
EAZIP                    6        A    Entity Postal Code
EAZIP4                   4        A    U.S. Plus 4 Postal Code
EACTRYCOD     10        A    Country Code
EAEFFDAT                 8   0    S    Entity Address Effective Date
EATRMDAT                 8   0    S    Entity Address Termination Date
EAMODUSR      10        A    Modified by User
EAMODPGM      10        A    Modified by Program
EAMODDAT       8   0    S    Modified Date
EAMODTIM                 6   0    S    Modified Time

Has worked well for me...

Regards

Rick DuVall
Systems Manager
Dealer's Auto Auction of Okc, Inc.
Rick@xxxxxxxxxx <mailto:Rick@xxxxxxxxxx>
(405) 947-2886


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Booth Martin
Sent: Monday, November 17, 2003 2:54 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: the idea of unique primary keys to be a solution
thathasoutlived its usefulness?


I am curious if i am alone on my thoughts about unique keys.  If there is 
a
very loud silence we will know that unique keys is the answer.  Is there
other ways to have various addresses without using defined record types as
part of the key.

*vbg*  (I have no delusions abut my weird ideas.)



---------------------------------------------------------
Booth Martin   http://www.MartinVT.com
Booth@xxxxxxxxxxxx
---------------------------------------------------------

-------Original Message-------

From: RPG programming on the AS400 / iSeries
Date: 11/17/03 14:12:28
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: the idea of unique primary keys to be a solution that
hasoutlived its usefulness?

In this case, I would have a separate file for addresses and use a type to
differentiate them.  We are, in fact, getting ready to develop a new
customer tracking database using a similar model.

Donald R. Fisher, III
Project Manager
Roomstore Furniture Company
(804) 784-7600 extension 2124
DFisher@xxxxxxxxxxxxx
_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.