På mit arbejde bruger vi UUID som PK'er. Hvad jeg kan fortælle dig af erfaring er, BRUG DEM IKKE som PK'er (i øvrigt SQL-server).
Det er en af de ting, at når du har mindre end 1000 poster, er det ok, men når du har millioner, er det det værste, du kan gøre. Hvorfor? Fordi UUID ikke er sekventielle, så hver gang en ny post indsættes, skal MSSQL gå og se på den korrekte side for at indsætte posten i, og derefter indsætte posten. Den virkelig grimme konsekvens med dette er, at siderne alle ender i forskellige størrelser, og de ender med at blive fragmenterede, så nu er vi nødt til at foretage defragmentering periodisk.
Når du bruger en autoincrement, vil MSSQL altid gå til sidste side, og du ender med lige store sider (i teorien), så ydeevnen til at vælge disse poster er meget bedre (også fordi INSERT'erne ikke blokerer tabellen/siden for så længe).
Den store fordel ved at bruge UUID som PK'er er dog, at hvis vi har klynger af DB'er, vil der ikke være konflikter ved sammenlægning.
Jeg vil anbefale følgende model:1. PK INT Identitet2. Yderligere kolonne genereres automatisk som UUID.
På denne måde er fletteprocessen mulig (UUID ville være din RIGTIGE nøgle, mens PK bare ville være noget midlertidigt, der giver dig god ydeevne).
BEMÆRK:At den bedste løsning er at bruge NEWSEQUENTIALID (som jeg sagde i kommentarerne), men for ældre app med ikke meget tid til at refaktorisere (og endnu værre, ikke at kontrollere alle indsatser), er det ikke muligt at gøre.Men faktisk fra 2017 vil jeg sige, at den bedste løsning her er NEWSEQUENTIALID eller at lave Guid.Comb med NHibernate.
Håber dette hjælper