I am amazed with how many people here have associated a clustered index with a primary key... That's the way the gui does it by default, but by no means does the clustered index have to be on a primary key. You can still have a primary key that isn't clustered on a table with a clustered index.

But, if the field(s) are not unique in the clustered index then a unique identifier will be added to the index. You just won't see it. This adds space to the table. General rule is to have your clustered indexes unique so the unique identifier isn't added. Remember too, that secondary indexes on a table with a clustered index point to the 'key value' in the clustered index (Great for index rebuilds). So any secondary indexes created on the table will have to have an extra column to provide for the unique identifier in the clustered index by date.

Basically, there isn't enough info provided to decide what the best choice would be. If there are 50 columns I would go with a covered secondary index. Etc. There are a lot of factors that should be included when deciding where, when, and how to create an index.