Re: Are primary keys always needed?

Rene,

In my experience it is always good to have a Key (whether you call it the PK or not is more a matter of convention IMHO). Basically not having a Key means that there is no way you can specifically address a particular record in the table using SQL. This may not sound like much of a problem for something like an event log, where you just want to list events in order of creation. Where it usually turns and bites is when some poor unfortunate DBA has to perform maintenance on the table, or someone decides that they want to address specific events in the application...

The only tables that I don't define a PK on are 'temporary' tables, which I use to hold intermediate results of queries. These tables must be able to handle duplicates, and any surrogate key would be redundant here. Note that I always discard all rows created at the end of my stored procedure, so this table is more of a programming convenience than a true representation of a relation.

HTH, David.

cshspcp_at_my-dejanews.com wrote:

> Hi everyone,
>
> I believe that all tables in a relational database should have primary
> keys. At least in theory, that's how is supposed to be.
>
> So, I need some practical examples (let's not talk theory here), as
> answers to the following questions:
>
> 1. Are there any cases in which a primary key is not required for a
> table? Or, Is there any good justification for having a table with NO
> primary key?
>
> 2. If a data model as some tables with no primary keys, does this mean
> that the model is NOT a GOOD data model, or is NOT AS GOOD AS it could
> be?
>
> Thanks in advance,
>
> Rene Pezo.
>
> --== Sent via Deja.com http://www.deja.com/ ==--
> ---Share what you know. Learn what you don't.---
Received on Thu May 20 1999 - 19:32:01 CDT