My objective is to set up the projected estimate for day by day basis in
ahead of time, then fill in the actual value when time comes. If today is
Jan 3rd, and we know yesterday's values, then,

Month           Day             Proj            Actual          Eff
Jan             1               11,000  10,500          95.5%
                2               12,440  11,200          90%
                3               11,223
..
Feb             1               10,003
                2               11,223
                3               12,330
..


-----Original Message-----
From: Rhino [mailto:[EMAIL PROTECTED]
Sent: Monday, October 18, 2004 11:14 AM
To: Scott Hamm; 'Mysql ' (E-mail)
Subject: Re: Date as Primary ID



----- Original Message ----- 
From: "Scott Hamm" <[EMAIL PROTECTED]>
To: "'Mysql ' (E-mail)" <[EMAIL PROTECTED]>
Sent: Monday, October 18, 2004 10:11 AM
Subject: RE: Date as Primary ID


> Ok, so that means what Jay Blanchard just now said recently wasn't
possible?
> I'm trying to figure out a way to ensure that date is not duplicated i.e.:
>
> create performance (
> `DateID` whatever,
> `Projected_Num` int(7),
> `Actual_Num` int(7),
> primary key [something to prevent DateID duplication]
> );
>
You could try something like putting the primary key on a combination of a
timestamp and another column. For example,

create performance (
`DateID` timestamp,
`col2` int,
`Projected_Num` int(7),
`Actual_Num` int(7),
primary key [DateID, col2]
);

You could populate col2 with an integer created via a random number
generator. There is always a small chance that a random number generator
would spit out the same random number twice but as long as it wasn't within
the same second, you should be fine. Please note that I am only speaking
theoretically and off the top of my head; I haven't actually tried this
suggestion.

A better solution might be to analyze your data more thoroughly. What is
this table trying to do? In other words, what do the rows in the table
represent in your business? Perhaps understanding that will help us choose a
better primary key. For example, if we fill in the blanks on the following
sentence, we may be able to get a better insight into the correct design of
this table:
Each row of the table contains the projected and actual number of
____________ [left-handled grapple grommets? widgets?] that will be
manufactured during this day of production. I suspect that the value that
you put into the blank will be the other half of your primary key.

To put it another way, I think the primary key of the table should be the
combination of the name of the product being manufactured and the date for
which the prediction is made.

Rhino

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to