Maybe it's cause they don't care?

-Amy

wrote in message
oups.com...

BruceM wrote:
To clarify, I am not going to use a multi-field PK when there are other
(and
simpler) means to guarantee uniqueness. If I have PartNumber and Process
(plating, welding, etc.) it makes sense to combine the two, since the
combination of Blade and Plating should appear just once.

I'll try one last attempt at getting the message across. Use your
multi-field PK to build the clustered index. The clustered index is
for that table and that table alone. Use your simpler 'PartNumber and
Process' in the FOREIGN KEY relationship. If it isn't already,
constrain 'PartNumber and Process' with NOT NULL UNIQUE. Remember that
you can have many NOT NULL UNIQUE constraints in a table but only one
clustered index (=PK)

It has a lot to do with reading what others have written here (people who
offer a lot pragmatic and practical advice, and who have demonstrated
again and again their command of the program)

Ask yourself: do these other people recommend an autonumber as PRIMARY
KEY in the knowledge that it creates a clustered index (physical
ordering)? I've yet to hear anyone here say, 'Yes, autonumber makes for
a fine clustered index.'