В моята работа използваме UUID като PK. Това, което мога да ви кажа от опит, е НЕ ГИ ИЗПОЛЗВАЙТЕ като PK (между другото SQL сървър).
Това е едно от онези неща, че когато имате по-малко от 1000 записа, всичко е наред, но когато имате милиони, това е най-лошото нещо, което можете да направите. Защо? Тъй като UUID не са последователни, така че всеки път, когато се вмъкне нов запис, MSSQL трябва да погледне правилната страница, за да вмъкне записа, и след това да вмъкне записа. Наистина грозната последица от това е, че страниците се оказват с различни размери и се оказват фрагментирани, така че сега трябва да правим периодично дефрагментиране.
Когато използвате автоматично увеличение, MSSQL винаги ще отиде до последната страница и в крайна сметка ще получите страници с еднакъв размер (на теория), така че производителността при избор на тези записи е много по-добра (също защото INSERT няма да блокират таблицата/страницата за толкова дълго).
Въпреки това, голямото предимство на използването на UUID като PK е, че ако имаме клъстери от DB, няма да има конфликти при сливане.
Бих препоръчал следния модел:1. PK INT Идентичност2. Допълнителна колона се генерира автоматично като UUID.
По този начин процесът на сливане е възможен (UUID ще бъде вашият РЕАЛЕН ключ, докато PK ще бъде просто нещо временно, което ви осигурява добра производителност).
ЗАБЕЛЕЖКА:Най-доброто решение е да използвате NEWSEQUENTIALID (както казах в коментарите), но за наследено приложение с малко време за рефакториране (и още по-лошо, че не се контролират всички вмъквания), не е възможно да се направи. Но наистина от 2017 г. бих казал, че най-доброто решение тук е NEWSEQUENTIALID или правенето на Guid.Comb с NHibernate.
Надявам се това да помогне
