On 2/17/06, Rick Morrision <[EMAIL PROTECTED]> wrote:
But in the larger question, why is a primary required in all cases?  What about the hypothetical use case for a table of of a loose collection of attributes, where dup records might be OK:

CREATE TABLE cust_notes (
   idcust int not null,
   note text
);

You mean you can't do an INSERT on this table with SA?

A strawman use case, sure -- but shouldn't we be able to handle it?

IMO, no.  This is a broken table.  Your db may allow it but from a relational standpoint this is simply broken.
 
There are a couple ways you could fix it.  One is simply a unique key on (id, note).  If you really wanted to allow duplicate texts, adding a time_entered field and create the unique key over all three might make sense.  But designing for indistinguishable, duplicate rows is broken; relational theory is set-based.  Ignoring this leads to ugliness and pain.

-Jonathan

Reply via email to