Op mijn werk gebruiken we UUID als PK's. Wat ik je uit ervaring kan vertellen is:GEBRUIK ZE NIET als PK's (SQL Server trouwens).
Het is een van die dingen die als je minder dan 1000 records hebt, oké is, maar als je miljoenen hebt, is dat het slechtste wat je kunt doen. Waarom? Omdat UUID niet sequentieel is, moet MSSQL elke keer dat er een nieuw record wordt ingevoegd naar de juiste pagina gaan om het record in te voegen en vervolgens het record in te voegen. Het echt lelijke gevolg hiervan is dat de pagina's allemaal in verschillende formaten terechtkomen en dat ze gefragmenteerd raken, dus nu moeten we periodiek defragmenteren.
Wanneer je een auto-increment gebruikt, zal MSSQL altijd naar de laatste pagina gaan, en je eindigt met pagina's van gelijke grootte (in theorie), dus de prestatie om die records te selecteren is veel beter (ook omdat de INSERT's de tabel/pagina niet blokkeren voor zo lang).
Het grote voordeel van het gebruik van UUID als PK's is echter dat als we clusters van DB's hebben, er geen conflicten zullen zijn bij het samenvoegen.
Ik zou het volgende model aanraden:1. PK INT Identiteit2. Extra kolom automatisch gegenereerd als UUID.
Op deze manier is het samenvoegproces mogelijk (UUID zou uw ECHTE sleutel zijn, terwijl de PK slechts iets tijdelijks zou zijn dat u goede prestaties geeft).
OPMERKING:dat de beste oplossing is om NEWSEQUENTIALID te gebruiken (zoals ik al zei in de opmerkingen), maar voor oudere apps met niet veel tijd om te refactoren (en erger nog, niet alle inserts te controleren), is het niet mogelijk om te doen. Maar inderdaad vanaf 2017 zou ik zeggen dat de beste oplossing hier NEWSEQUENTIALID is of het doen van Guid.Comb met NHibernate.
Ik hoop dat dit helpt