Re: Multi-Field Primary Key
- From: "Van T. Dinh" <VanThien.Dinh@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 6 Jan 2007 13:53:26 +1100
It is probably more important for the Inner Join to put an Index on the
ForeignKey [frg_PHONE] in the "Many" Table in this case.
Something troubles me: Do you have Activities that don't involve [PHONE]?
--
HTH
Van T. Dinh
MVP (Access)
"nickh" <nickh@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:DBEEC626-99EF-45F1-942A-7FD478282CE4@xxxxxxxxxxxxxxxx
I use the [PHONE] portion only to link in one-to-many to another table that
contains records of activity on that [PHONE]. I am assuming that the
primary
key designation causes a faster lookup during an innerjoin than just an
indexed field? (Is that assumption correct?) I.E., the
[PHONE]+[AUTONUMBER]
would be in the same position in the primary key index as [PHONE] alone,
but
the [PHONE]+[AUTONUMBER] achieves uniqueness whereas [PHONE] alone isn't.
Actually the problem is that a lot of records have a null [PHONE] (because
we
don't have a phone], so then we need the [AUTONUMBER] portion to achieve
uniqueness. So with your ZLS the index would look like
""1
""154
""894
""954
et cetera
whereas the non-null records would have 10-digit [PHONE] + [AUTONUMBER]:
2125551212955
2135551212956
2145551212957
et cetera
Maybe my logic is just totally flawed here. I always learned in db class
that the primary key is faster than just indexing alone, so you always
want
to try to create a primary key to maximize the speed of lookups and joins.
.
- References:
- Re: Multi-Field Primary Key
- From: Allen Browne
- Re: Multi-Field Primary Key
- From: nickh
- Re: Multi-Field Primary Key
- Prev by Date: Re: Stock Performance
- Next by Date: Re: Database Properties : Date Created vs DateCreated
- Previous by thread: Re: Multi-Field Primary Key
- Next by thread: Re: Multi-Field Primary Key
- Index(es):
Relevant Pages
|