title: Alternatives to GUID for clustered index
body: <p>I have the following situation: I'm creating a database that will work locally, but can be migrate to a online database that have the same schema and will already have some data. For this reason, I'm planning to use GUIDs as the primary keys for it's tables, as it will make migrations easier by avoiding the need to change primary key values (and cascading it to referencing tables) that would occur if I use any identity column (am I right?). The database is build on SQL Server 2012.</p>
  
  <p>Despite this, I would like to have a clustered index to speed up queries on the database tables, and as I read many articles and Stack Overflow answers, I'm convinced that having a clustered index on a GUID primary key is not a good idea. So, the question is: is there any good solution to have a clustered index on this database tables? I'm open to removing the GUIDs and adding another data type. For a second I thought of using a HiLo approach, but I think that it would make the migration harder, which is an option, but I need a really good reason to choose it (namelly, if there is no good way to use a GUID ad PK and speed up queries).</p>
  
  <p>Until now I thought of these solutions:</p>
  
  <ul>
  <li>Using newsequentialid() to generate the new GUIDs, making them sequential and better as a clustered index. The question here is: is this really any better than using a int primary key? The main reason here to use GUIDs is to help with any migration that will eventually happen, and I think that making them sequencial would not help here. Plus, I would have to retrieve the db generated GUID instead of create it on the client side.</li>
  <li>Using a <a href="http://www.informit.com/articles/article.aspx?p=25862&amp;seqNum=10" rel="nofollow">COMB GUID</a> and making it also the clustered index. It seems to solve some problems that exist in the previous approach, while keeping a high "randomness factor", but I don't know if there are any outcomes. Is there?</li>
  <li>Adding a identity int column with and using it as the clustered index. My question here is if it will help on anything, since the queries will be made with the PK value anyway, which is a GUID.</li>
  <li>Slightly chance the previous approach, turning the identity int into the primary key value and clustered index, and adding a GUID collumn with which I would make the queries. I see that on Adventure Works 2012 this is the choice, but I don't really understand where it helps... will the clustered index help if I query the values with the GUID, which is not the PK nor clustered?</li>
  </ul>
  
  <p>I think thats all that I could come up with, and I'm really inclined to choose the COMB approach, and thinking on some experiments to validate if and why it's better. But is there a better solution in this scenario?</p>