Re: does a table always need a PK?

From: Venkat <reddyp_at_mindspring.com>
Date: Sat, 23 Aug 2003 14:28:27 -0400
Message-ID: <bi8bod$6h4lp$1_at_ID-143233.news.uni-berlin.de>


"Paul" <paul_at_not.a.chance.ie> wrote in
> 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.

Paul,

    You are confusing an index with a key. Index is physical, while a key is logical. Not all keys need to have a related index. Even if the key has an associated index, it need not be used in the queries. For example, some RDBMSs don't create indexes (indices) for the foreign keys, while some of them create the associated index automatically. In some RDBMSs, even the unique indexes for the primary/unique key have to be explicitly created.

> AFAIK, this is true for the RDBMS's that I use (Interbase, FireBird and
> PostgreSQL).
>
>
>
> Any thoughts, rants, references, URLs on this topic welcomed.

Here is one URL that might be of use:
http://www.aisintl.com/case/relational_keys.html

> p.s. just lacerated a tendon in left hand, so pls
> excuse typos and tricky abbrevs - TIA.

    Hope you get your tendon fixed soon.

  • Venkat
Received on Sat Aug 23 2003 - 20:28:27 CEST

Original text of this message