Gila answered one of my questions about the unique constraint/unique index already.
I do still have a question about the when to use clustered indexes section though. The sentence below makes sense to me.
Most often you'll make the primary key an IDENTITY column, so each new record is assigned a unique, ever increasing number. This means that if you put the clustered index on the primary key, new records are always added at the end of the table without page splits.
My question though is what if you have a table named Customers with a CustomerID primary key. CustomerID is is a uniqueidentifier. I have another table named PhoneNumber with a PhoneNumberID int identity and CustomerID is a FK that references Customers. I know I could create a clustered primary key on the PhoneNumberID integer and a nonclustered index on CustomerID. But, none of my queries/stored procedures reference the PhoneNumberID. They all do something similiar to "WHERE CustomerID = @CustomerID". Would it make more sense to make the PhoneNumberID field a nonclustered primary key to guarantee uniqueness in the table and put the clustered index on the CustomerID even though it's a uniqueidentifier?
Some small testing that I did seems to suggest that the latter seems to perform better than the former but I want to make sure I'm not missing anything. I'm also trying to figure out how it will perform once my application starts to scale out and we go from say a couple hundred customers to a couple hundred thousand customers and more.