Re: does a table always need a PK?

"Paul" <paul_at_not.a.chance.ie> wrote in message news:MPG.19b1b482826a20ab989723_at_news1.eircom.net...
>
> cbbrowne_at_acm.org says...
>
> > You almost certainly should have a UNIQUE primary key on every relation.
>
>
> Maybe this true in theory, but not essential in practice?
>
> I'm not being facetious here.
>
>
> Take an example that I recently worked on - we have a lookup table of 26
> counties (in Ireland) which really has a very small about of data in it,
> say max. 1.5K.
>
>
> Now, as I understand it, RDBMS's will look at the size of a table before
> scanning it to see if it's worthwhile using an index, and if the table
> is too small, it'll just perform a straigh scan anyway and not bother
> with the index, even if you've gone to the trouble of putting one in.
>
>
> AFAIK, this is true for the RDBMS's that I use (Interbase, FireBird and
> PostgreSQL).

Uniqueness is a logical constraint independent of any physical structure like an index. It is true that SQL generally confuses the two levels by making uniqueness an attribute of an index.

Without any uniqueness, how do you plan to distinguish between rows? Received on Sun Aug 24 2003 - 01:42:02 CEST