RE: the idea of unique primary keys to be a solution that hasoutl ived its usefulness?

It is simply amazing to me that as fast as we move forward, we move
backwards. I can remember writing applications on the System/38 that were
all based on a 10 digit key field. All relationships were stored based on
the keys of 10 digits.
I can remember the people saying how wonderful it was to work in a shop
where you could use real fields as keys.

John Brandt
iStudio400.com 

-----Original Message-----
From: Haas, Matt [mailto:Matt.Haas@xxxxxxxxxxx]
Sent: Wednesday, November 19, 2003 10:43 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: the idea of unique primary keys to be a solution that
hasoutlived its usefulness?


Of course, the problem with using the RRN as the primary key is that it may
change if a file is reorged which breaks the relationship.

A better approach (assuming you're on a release that doesn't have an
auto-increment field) would be to use either a self-written auto-increment
routine or assign either a GUID or UUID as the primary key. Our B2C
ecommerce package uses GUID's as primary keys so it doesn't have to deal
with the differences in how auto-increment fields work among the various
databases it supports.

Matt

-----Original Message-----
From: John Brandt Sr. [mailto:pgmr@xxxxxxxxxxxxxxx]
Sent: Wednesday, November 19, 2003 11:12 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: the idea of unique primary keys to be a solution that
hasoutlived its usefulness?


Eric,
Given that scenario, the relative record number on a physical (auto number)
should be the only key to a file. You can use logicals or SQL to perform all
joins.

John Brandt
iStudio400.com

-----Original Message-----
From: DeLong, Eric [mailto:EDeLong@xxxxxxxxxxxxxxx]
Sent: Wednesday, November 19, 2003 9:53 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: the idea of unique primary keys to be a solution that
hasoutl ived its usefulness?


Joep,

Yes, I'll agree that compound keys can indeed be considered primary keys.  I
misspoke; I was thinking of "identity columns" which are commonly used in
databases as primary key.  

The difference between the two designs, imo, is that the widespread use of
compound keys makes for inefficient joins between tables.  

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-898-7863 or ext. 1863



-----Original Message-----
From: Joep Beckeringh [mailto:joep.beckeringh@xxxxxxxxxx]
Sent: Wednesday, November 19, 2003 2:47 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: the idea of unique primary keys to be a solution that
hasoutl ived its usefulness?


----- Original Message -----
From: "DeLong, Eric" <EDeLong@xxxxxxxxxxxxxxx>
To: "'RPG programming on the AS400 / iSeries'" <rpg400-l@xxxxxxxxxxxx>
Sent: Monday, November 17, 2003 10:24 PM
Subject: RE: the idea of unique primary keys to be a solution that hasoutl
ived its usefulness?


> Unique primary keys are not what most of us use on the iSeries.  We use
> unique compound keys, where the combination of many factors (keys) work
> together to define a unique row.  Unique primary keys are a single field
> that describes a unique row.  These are commonly implemented as UUIDs, or
> possibly as auto-incrementing value for such things as order number and
> whatnot...

Who says so? Primary keys can be compound.

>From 'A Guide to the SQL Standard' (C.J. Date / Hugh Darwen):

In SQL, a candidate key definition takes the form
    { PRIMARY KEY | UNIQUE } ( column-commalist ).
For a given base table, at most one candidate key definition can specify
PRIMARY KEY.

Joep Beckeringh

_______________________________________________
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.

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.541 / Virus Database: 335 - Release Date: 11/14/03
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.541 / Virus Database: 335 - Release Date: 11/14/03