One guideline I strongly disagree with...
Avoid Nonclustered, Unfiltered Indexes on Columns that have few Distinct Values
The old cliché is “Never index the Gender column”. A typical page of the table will have half female rows and half male rows, and will be accessed whether the request is for female rows or for male rows. A table scan will always be the best decision for any WHERE GENDER = … query; therefore, such an index will never be of benefit to the optimizer.
Not at all. While an index on just the Gender column may not be very useful, an index that starts with the gender column, perhaps has other key columns and maybe an include column or two can be very, very useful indeed, especially if you have a lot of queries that filter on gender and ...
A table scan will not always be the best decision for a filter on a high density column (high density = not very unique). If the index on the column is covering, seeks can and will be used even up to cases where 100% of the rows in the table affected by the query.
Also
Consider Using a Foreign Key in the Search Key of the Clustered Index
Maybe, but by doing so you're losing the ever-increasing attribute that is suggested for clustered indexes and maybe (depending what the other key columns are and if the foreign key every changes) the narrow, unchanging and unique as well
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability