>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.

Thanks, I did not think about the tinyint until well after I started developing. I don't think I will be hurt too much though by using bit fields. The table has only 12,000 records, so hopefully I lucked out a bit there.

>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.

I had not thought of this. I have a field named Symbol in the Company table (corresponds to the company's stock ticker symbol), and I ORDER the result set by this field.

>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.

Are you sure about this? In the Financial table, the PK is FinancialID (surrogate integer), while the foreign key is CompanyID (surrogate integer). I perform calculations throughout the day on a set of Financial records for a given company. Shouldn't the clustered index be on CompanyID so that all of a company's financial records are grouped together?