title: Merging two tables, duplicate keys
body: <p>*I'm very new to this, I might (probably will?) be talking some jibberish now and then, feel free to correct me ;)</p>
  
  <p>I'm playing around with different primary key/index strategies and was wondering about the following. In many cases the choice for a GUID as the primary key is providing the record with unique identification across any database.</p>
  
  <p>Now there are some performance issues with using GUIDs as primary key (and default behaviour of using it as the clustered index). There are a few alternatives one can think of, like using  NEWSEQUENTIALID() or adding an extra IDENTITY column to provide a sequential clustered index.</p>
  
  <p>Another one is doing away with GUIDs in the primary keys (and indexes) all together, while supplying a column for unique identification across the globe, an external identifier/rowid.
  This leaves you with smaller tables. Of course, there is the 16 byte penalty of the additional column, but this is quickly diminshed in tables with a few FKs. More stuff on the pages, nice sequential ids, smaller index space, so win win win.</p>
  
  <p>This approach however leaves us with a nasty drawback: when you want to merge 2 tables, you get stuck with duplicate keys. Now, I'm not advocating this approach, I'm merely exploring and comparing different strategies in order to make me more versed in this part of database design.</p>
  
  <p>The question is: How can we use the uniqueness of the GUID in this situation to deal with the duplicate key problem? Should one disable all table constraints and generate the IDENTITYs as the table gets merged? Should this approach be discarded entirely?</p>