På mitt jobb använder vi UUID som PK:er. Vad jag kan säga dig av erfarenhet är ANVÄND DEM INTE som PK:er (SQL-server förresten).
Det är en av de saker som när du har mindre än 1000 poster är det ok, men när du har miljoner är det det värsta du kan göra. Varför? Eftersom UUID inte är sekventiella, så varje gång en ny post infogas måste MSSQL gå och titta på rätt sida för att infoga posten och sedan infoga posten. Den riktigt fula konsekvensen med detta är att sidorna hamnar i olika storlekar och de slutar fragmenterade, så nu måste vi göra defragmentering med jämna mellanrum.
När du använder ett autoinkrement kommer MSSQL alltid att gå till sista sidan, och du slutar med lika stora sidor (i teorin) så prestandan för att välja dessa poster är mycket bättre (även eftersom INFOGARNA inte blockerar tabellen/sidan för så länge).
Den stora fördelen med att använda UUID som PK:er är dock att om vi har kluster av DB:er kommer det inte att uppstå konflikter vid sammanslagning.
Jag skulle rekommendera följande modell:1. PK INT Identitet2. Ytterligare kolumn genereras automatiskt som UUID.
På så sätt är sammanslagningsprocessen möjlig (UUID skulle vara din RIKTIGA nyckel, medan PK bara skulle vara något tillfälligt som ger dig bra prestanda).
OBS:Att den bästa lösningen är att använda NEWSEQUENTIALID (som jag sa i kommentarerna), men för äldre appar med inte mycket tid att återställa (och ännu värre, inte kontrollera alla insatser), är det inte möjligt att göra. från och med 2017 skulle jag säga att den bästa lösningen här är NEWSEQUENTIALID eller att göra Guid.Comb med NHibernate.
Hoppas detta hjälper