Re: What do you do with an ENORMOUS primary key?

In article <aerjeu$guk$1_at_lust.ihug.co.nz>, you said (and I quote):
> Suppose I have a table as follows:
>
> Create table STANDARDS (
> asstcode varchar2(3),
> jobcode number(5,0),
> season varchar2(3),
> period number (2,0),
> week number (2,0),
> day varchar2(3))
>
> In other words, an asset can have all sorts of jobs performed to it, and
> those jobs can be scheduled to occur 'sometime in Spring', or 'sometime in
> March', or sometime in week 16, or on Thursday.
>

Hmmmm, just a few thoughts:

ASSET table. With obviously asset code there, plus whatever else you may need.

JOB table. With jobcode there, plus whatever else you may want to define the job with (interruptible, recoverable, restartable, that sort of jazz).

JOBSCHED table. Intersects both of the above. With the date/timespan attributes there.

In practice, you may well find that having surrogate keys (PKs out of sequences and generated by trigger) is a better solution than using the *code attributes as your PKs.

This mostly because in a hierarchy, if anyone wants to reassign the code of a given product and that code is sprinkled all over the place as a FK, you have a major task in your hands.

With a surrogate key, the code is just a unique key attribute. The surrogate key is all over the place as a FK, but you never need to update it. Just create or delete.

Just my 0$02 worth.

-- 
Cheers
Nuno Souto
nsouto_at_optushome.com.au.nospam