Okay, but you are measuring the projected number of units of *something*, right? The number of widgets made, the number of gadgets sold, the number of x-rays taken or whatever. I think you need that *something* as a column in the table.
Hmm. On second thought, if you are only making or selling a single thing, let's call it a 'foo', then every row in the table would contain 'foo' as the object being made or sold and it would be trivial to put the value 'foo' in every row and to make it a part of the primary key. In that case, is it true that there would only be one row for each day and that the row would represent that day's production or sales, projected and actual? If the answer to that question is yes, then your primary key is simply the date, consisting of year, month and day, not a timestamp, and you don't need any additional columns. Rhino ----- Original Message ----- From: "Scott Hamm" <[EMAIL PROTECTED]> To: "'Rhino'" <[EMAIL PROTECTED]>; "'Mysql ' (E-mail)" <[EMAIL PROTECTED]> Sent: Monday, October 18, 2004 11:19 AM Subject: RE: Date as Primary ID > 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] > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
