Re: are primary keys always 'needed'

Thanks for the reply.

>> Some have a serial that is used as a foreign key in another table.
>> Some tables consist of a combination of two foreign keys (that are
>> unique together) and a field that is uniquely related to that
>> combination (but is not necessarily unique within the table)
>
> BTW, I forgot to mention that it's perfectly reasonable to have a
> multi-column primary key, which is what seems to be indicated in
> this type of example.  I wouldn't advocate making up a surrogate
> primary key in a linking table, if the combination of its foreign
> keys can do the job.

So when I have a table that exists only on the MANY-end of the
relation and in now way is ever to be used as a an entity in the
ONE-end of the relatonship.
There are no benefits to specifying a primary key if a combination of
two fields (that already have a unique not null constraint anyway) to
replace those with a primary key?

Are there any other benefits to a primary key other than unique not
null constraints.
For performance.
For example, if I create a primary key that is never used in any
query, but its just there'  to make the row unique.

Based on what you stated so far, I'd think:
A primary key is not necessary, but useful in uniquely identifying a record.

Thanks so far.

Regards,

Serge Fonville

--
http://www.sergefonville.nl

Convince Google!!
They need to support Adsense over SSL
https://www.google.com/adsense/support/bin/answer.py?hl=en&answer=10528
http://www.google.com/support/forum/p/AdSense/thread?tid=1884bc9310d9f923&hl=en