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

Hi John,

Yup. That's what I used to do (I think I included the details elsewhere in this thread: 1-4 for a season; 1-13 for a period; 51-103 for a week; 0.1-0.7 for a day). I wanted to aviod that this time.

But it seems to have the merit of keeping the index simple, like a syntetic key, and yet have real meaning. So I might revert.

Thanks.
Regards
HJR "John Russell" <netnews3_at_johnrussell.mailshell.com> wrote in message news:l9f9husobqnu4nmuurpbs7a51ifv5pgt5s_at_4ax.com...
> On Fri, 21 Jun 2002 06:25:29 +1000, "Howard J. Rogers"
> <dba_at_hjrdba.com> wrote:
> >So real dates and hence date ranges are out of the question, I'm afraid.
But
> >I appreciate your thoughts nonetheless.
> ...
> >> > Create table STANDARDS (
> >> > asstcode varchar2(3),
> >> > jobcode number(5,0),
> >> > season varchar2(3),
> >> > period number (2,0),
> >> > week number (2,0),
> >> > day varchar2(3))
> ...
> >> > My trouble is that since an assett can have many jobs scheduled for
it,
> >> and
> >> > each job can be scheduled many times, the entire table is the entire
> >> primary
> >> > key.... and that doesn't feel right to me.
>
> How about hashing all these values into a single integer value, then
> using that as the primary key?
>
>

http://otn.oracle.com/docs/products/oracle9i/doc_library/release2/appdev.920 /a96612/d_util2.htm#1002139
>
> You'd just have to concatenate everything into a single string in your
> trigger or stored function. Don't know to what degree this
> *guarantees* uniqueness, if the calls are done over multiple sessions.
>
> John
> --
> Got an Oracle database question?
> Try the search engine for the database docs at:
> http://tahiti.oracle.com/
>
> The opinions expressed above are mine and do not
> necessarily reflect those of Oracle Corporation.
Received on Sat Jun 22 2002 - 17:53:20 CDT