>If I understand correctly then this really wouldn't have much effect on what I'm doing since I already have a bunch of fields that are big so what having another field that is big (when I mean big, probably my limit for the primary key would be 25 characters) is just normal.

True, you do have to consider the size of the existing row. if the existing row is 100 bytes, then you're currently getting 80 rows/page. Increase the row size to 125 and you be getting 64 rows/page.

Likewise, if the current row is 1000 bytes, you're getting 8 rows/page. Increase the size by 25 bytes => 7 rows/page. 1 Million rows @ 8 rows/page = 125K pages. @ 7 rows/page = 143K pages. That's a lot more that SQL Server has to do.

>I think I need to take a look at this, so what you're saying is that the non-clustered keys will be slower? or maybe noticibly slower?

Technically it would have to be slower since there would be more pages to scan through. Whether you would see it or not is another story.

-Mike

>Thanks for the response Michael,
>
>Let me analyze the 2 major points that you made.
>
>"The more space that a row takes up, the less rows that SQL Server will be able to place on an 8K page. This means that SQL Server will have to do more I/O to retrieve the data"
>
>If I understand correctly then this really wouldn't have much effect on what I'm doing since I already have a bunch of fields that are big so what having another field that is big (when I mean big, probably my limit for the primary key would be 25 characters) is just normal.
>
>"In your example, if cStatus_ID has a clustered index on it, the key will automatically become part of any non-clustered index that you create on the table, making the non-clustered key larger so that there are less keys on any one page."
>
>I think I need to take a look at this, so what you're saying is that the non-clustered keys will be slower? or maybe noticibly slower?
>
>
>Thanks.