In my original request on Connect (
) I made the point that GUIDs should not be created on the db side as a Clustered Index, possibly very poorly at the time.
Basically, GUIDs when inserted in as a clustered index primary key means that the table gets a perf hit as it needs to re-sort and insert the new row where appropriate.
The work item you redirected me to shows your plan is to use sequential uniqueidentifiers to "fix" this:
Instead I'd like you to discuss just creating it as a Non-clustered Index Unique Constraint on the database side - you still get the primary key, you still get it indexed but you don't suffer the performance hit on the database - if this isn't the case as I
believe and have read and been told by SQL MVP's then I'd be happy if you loop someone in on the discussion to correct me.
That way we can still create random GUIDs on the client side, we can also insert new records in multiple instance of the database and not have replication concerns, and we don't need to resort to using sequential uniqueidentifiers on the database.