>Let me start by saying I take no responsibilty for this post and I will deny posting it if confronted. ;-) (I just had to throw that in there because you have been participating in that other thread about responsibilties of people with TLA after their name.)

But you are part of the inner sanctum. I would not pick on you. < g >

>Okay. IMO, the clustered index would probably be a good idea on the Financial table but not on the Company table. Clustered indexes are used to decrease the number of pages returned. Having a clustered index on the PK doesn't help with this objective. Because you are basing your query on other fields, the valid rows could exist throughout the table.

I thought the other advantage of clustered indexes is that when SQL Server traverses the B-tree, when it gets to the leaf, it is already at the data. This is maybe where I am getting confused. I thought that since I am using a surrogate key (I can't remember if I mentioned this), an integer generated sequentially, that SQL Server would find the leaf more quickly.

>Having a clusterd index on the Financials table does help with this objective. Once you get the necessary keys from the Company table, it may be as simple as returning 1 page in the Financials table. The query would be very fast.

Very cool.

>FWIW, if you do go with a clustered index on the Financials table, I recommend dropping the clustered index before doing the updates (you may already do this). The reason is that each time you add or update a record with a clustered index, the entire indexing structure must be rebuilt. It is better to drop the clustered index, make all the updates you need to and then rebuild the indexes once.

Good suggestion. I had not thought of this.