>Am I right in assuming that a clustered index on the CompanyID field is a good idea for the Company table, and a clustered index on the CompanyID field is a good idea for the Financial table?

You cannot index bit fields. Everytime you search the Company table, SQL Server will have to do a table scan. Can you convert them to the tinyint data type? I realize that it's eight times bigger but at least you can index it.

As for the Clustered index on Company, since you can't use it for searching, maybe you can place it on a column that you sort by. That way, SQL Server won't have to do an actual sort, the data will physically exist in the order of the Clustered index. The only exception might be if the column is very large. On a table with a Clustered index, the clustered-key becomes part of every non-clustered key. The smaller we can keep the keys, the more keys that will fit on a page, the less work SQL Server must do to find a row.

If you don't sort the data the same way constantly, what about range queries? Do you search between dates alot? Then put the Clustered index on the date column. Otherwise I'd leave the Clustered index on the PK. It will help when SQL Server is enforcing DRI.

For the Financial table, leave the Clustered index on the the PK.

-Mike