On Tuesday 13 March 2001 2:26 pm, Brett W. McCoy wrote:
> Not a moderated list.
Ah well, sorry for the duplicates.
Thanks for the answer, though!
> > id | make | model | year | value
> > ---------+-----------+--------+-------+-------
> > 57 | 2 | 0 | 4 | 4750
> > 57 | 2 | 3 | 4 | 4750
> > 57 | 2 | 0 | 0 | 4750
> > 57 | 2 | 0 | 3 | 4750
> > 57 | 2 | 3 | 0 | 4750
> > 57 | 2 | 3 | 3 | 4750
> > 2 | 2 | 0 | 3 | 4750
> > 2 | 2 | 3 | 3 | 4750
> > 2 | 2 | 0 | 4 | 4350
> > 2 | 2 | 3 | 4 | 4350
> > 2 | 2 | 0 | 0 | 4750
> > 2 | 2 | 0 | 5 | 4750
> > 2 | 2 | 3 | 0 | 4750
> > 2 | 2 | 3 | 5 | 4750
>
> The potential for duplicate records is rampant here. What is the primary
> key? Do these values use foreign keys?
The primary key is id/make/model/year, sorted by sum(value).
Doh! I think I forgot to mention a critical part: selects on the table vary
model and year to be either '0' (which represents 'all') or the specific
number concerned.
So, there are 4 ways to slice this data:
a particular make, all models, all years
a particular make, particular model, all years
a particular make, all model, particular years
a particular make, particular model, particular years
> > Everything is working swimmingly, except for the numbering magic. As you
> > can see there are several variations of data in that table, so I can't
> > use a serial on the table directly.
>
> Why not? The serial number can be used exclusively for identifying a
> unique row. That's definitely the easiest way to do this numbering.
>
> > Further, this table is likely to change on a minute by minute basis, so I
> > don't want to create a permanent numbering that will just have to be
> > changed.
>
> Ah, that is a problem.
Because different rows get used depending on which 'slice' you use (as
defined above).
--
Ken Corey, CTO Atomic Interactive, Ltd. ken.corey@atomic-interactive.com