Re: all foreign key should have index?

From: Gene Wirchenko <genew_at_ucantrade.com.NOTHERE>
Date: Thu, 02 Feb 2006 09:58:26 -0800
Message-ID: <rrh4u1lp333g6qj9c9ee2nmblk5i4gl22f_at_4ax.com>


On Thu, 2 Feb 2006 10:23:12 +0000 (UTC), "Murdoc" <murdoc_0_at_hotmail.com> wrote:

>Gene Wirchenko wrote:
>
>> On Wed, 1 Feb 2006 20:17:11 +0000 (UTC), "Murdoc"

[snip]

>> > Again, it does come down to the size of the table. A table with a maximum of about 10 rows is
>> > not going to have a large performance gain with an index (or maybe a performance detriment).
>>
>> That is not the point. Why does it have to be an INDEX?
>>
>> You have been assuming that an index is the only way. It is not.
>
>Then what is the other way? What other mechanism allows efficient searching of a table without a
>full search?

     Why eliminate full table scans? In some cases, it might be faster than the overhead of an index. (If there are very few entries.)

     What about hashing? If you had an environment where there could not be any collisions, it could be much faster than an index.

     Indexes are a good general solution. That does not make them the only one.

Sincerely,

Gene Wirchenko Received on Thu Feb 02 2006 - 18:58:26 CET

Original text of this message