RE: SQL descending primary key

i wouldn't...i can use the table as is in RPG, etc. why add the extra

overhead for an identical key??

I agree I wouldn't (see above). However, there should be no additional
overhead. The two indexes should share a common access path.

I think that it's the indexes are shared, where possible, between access
paths rather than the other way round.

For example, an access path has 3 key fields in order: A, B and C. Creation
of this access path will result in 1 index. If a second access path is then
required with 2 key fields A and B then, on creation, will use the existing
index. So we have two access paths and only one index. However, if the two
access paths were created in reverse order then we'd have 2 indexes with the
associated overhead.

Cheers,

Keith



Help cut carbon...please don't print this email unless you really need to

Hastings Insurance Services Ltd trading as Hastings Direct is an independent intermediary, authorised and regulated by the Financial Services Authority. Registered in England No: 3116518. Registered Office: Conquest House, Collington Avenue, Bexhill-on-Sea, East Sussex, TN39 3LW.

CONFIDENTIALITY. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named recipient, please notify the sender immediately at mailto:postmaster@xxxxxxxxxxxxxxxxxx and do not disclose the contents to another person, use for any purpose, or store or copy the information in any medium. Please note that any views expressed in this message are those of the individual author and do not necessarily represent those of Hastings Insurance Services Ltd.

This email has been scanned by Mailcontrol from Blackspider.