RE: Database design question

["Musselman, Paul" <pmusselman@xxxxxxxxxxxxxxxx>]

We never had (many) issues with corruption-- after we had fun with some 3rd party disks on the S/38, the disk vendor upgraded the disks so we could use CheckSum (?) (ie software RAID), and enough extra memory so we wouldn't feel any degradation-- we've been RAIDed ever since!

Paul E Musselman
PaulMmn@xxxxxxxxxxxxx

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Campin
Sent: Monday, August 28, 2017 4:50 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: Database design question

Yep, in the bad old days you never put a key on the physical because of
corruption but with today's hardware it just never happens or at least I
have not seen it in many, many moons.

On Mon, Aug 28, 2017 at 1:44 PM, Musselman, Paul <
pmusselman@xxxxxxxxxxxxxxxx> wrote:

> Ours as well--  IIRC, in the early S/38 / AS/400 days the thought was that
> since a Physical File consisted of the data portion and an index, you were
> out of luck if the index got corrupted-- you'd lose your master file!
>
> Of course, in most cases you could CPYF FROMRCD(1) to read by RRN instead
> of by key, and salvage your data.
>
> The problem was overblown; but some applications...
>
>
> Paul E Musselman
> PaulMmn@xxxxxxxxxxxxx
>
>
> -----Original Message-----
> From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
> Rob Berendt
> Sent: Monday, August 28, 2017 1:58 PM
> To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> Subject: RE: Database design question
>
> *SNIP*
>
> That being said however, our ERP package has no primary nor unique keys on
> the underlying table.  They have a key on some of the logicals but do not
> specify unique.  In theory you could have duplicate keys but their
> programming logic doesn't permit it (from transactions done within the
> programming logic).
>
> I think the thing was 40 years ago there was certain corruption which was
> easier to recover from if your table did not have any keys on it.  Don't
> laugh, I think that is really the reason.
>
> *SNIP*
> --