Nel mio lavoro, usiamo UUID come PK. Quello che posso dirti per esperienza è NON USARLI come PK (SQL Server tra l'altro).
È una di quelle cose che quando hai meno di 1000 record va bene, ma quando ne hai milioni, è la cosa peggiore che puoi fare. Come mai? Poiché gli UUID non sono sequenziali, quindi ogni volta che viene inserito un nuovo record, MSSQL deve guardare la pagina corretta in cui inserire il record e quindi inserire il record. La conseguenza davvero brutta con questo è che le pagine finiscono tutte in dimensioni diverse e finiscono per frammentarsi, quindi ora dobbiamo eseguire la deframmentazione periodica.
Quando usi un incremento automatico, MSSQL andrà sempre all'ultima pagina e ti ritroverai con pagine di dimensioni uguali (in teoria), quindi le prestazioni per selezionare quei record sono molto migliori (anche perché gli INSERT non bloccheranno la tabella/pagina per così a lungo).
Tuttavia, il grande vantaggio dell'utilizzo di UUID come PK è che se disponiamo di cluster di DB, non ci saranno conflitti durante l'unione.
Consiglierei il seguente modello:1. PK INT Identità2. Colonna aggiuntiva generata automaticamente come UUID.
In questo modo, il processo di unione è possibile (l'UUID sarebbe la tua VERA chiave, mentre la PK sarebbe solo qualcosa di temporaneo che ti offre buone prestazioni).
NOTA:Che la soluzione migliore sia usare NEWSEQUENTIALID (come dicevo nei commenti), ma per le app legacy con poco tempo per il refactoring (e peggio ancora, non controllando tutti gli inserti), non è possibile farlo. Ma in effetti a partire dal 2017, direi che la soluzione migliore qui è NEWSEQUENTIALID o fare Guid.Comb con NHibernate.
Spero che questo aiuti
