In article <010601c54a6d$244a7fc0$2801a8c0@localdomain>,
"Jigal van Hemert" <jigal@stripped> writes:
> From: "Harald Fuchs"
>> > id INT(11) - accountID
>> > name VARCHAR(32) - parameter name
>> > value INT(11) - parameter value
>> > Other tables contain string, datetime, etc. parameters.
>> > Since most searches are made for a value (or range) of one or more
>> > parameters, a usable primary key is:
>> > name-value-id
>> That's a horrible denormalization. If one named parameter can hold
>> only one INT value for one account id, then (id, name) could be a
>> primary key; otherwise, you'd need a surrogate primary key.
> How would *you* normalize this situation? All suggestions are welcome!
Your table structure is fine AFAICS, but a primary key should span a
minimum number of columns uniquely identifying a single row. "value"
does not meet that need.