W mojej pracy używamy UUID jako PK. Z doświadczenia mogę powiedzieć, że NIE UŻYWAJ ICH jako PK (przy okazji, SQL Server).
To jedna z tych rzeczy, które kiedy masz mniej niż 1000 płyt, to ok, ale kiedy masz miliony, to najgorsza rzecz, jaką możesz zrobić. Czemu? Ponieważ UUID nie są sekwencyjne, więc za każdym razem, gdy wstawiany jest nowy rekord, MSSQL musi przejrzeć właściwą stronę, aby wstawić rekord, a następnie wstawić rekord. Naprawdę brzydką konsekwencją tego jest to, że wszystkie strony mają różne rozmiary i są pofragmentowane, więc teraz musimy przeprowadzać okresową defragmentację.
Kiedy używasz autoinkrementacji, MSSQL zawsze przejdzie do ostatniej strony i skończysz z tymi samymi rozmiarami stron (teoretycznie), więc wydajność wybierania tych rekordów jest znacznie lepsza (również dlatego, że INSERT nie będą blokować tabeli/strony dla tak długo).
Jednak dużą zaletą używania UUID jako PK jest to, że jeśli mamy klastry DB, nie będzie konfliktów podczas łączenia.
Polecam następujący model:1. PK INT Tożsamość2. Dodatkowa kolumna generowana automatycznie jako UUID.
W ten sposób proces łączenia jest możliwy (UUID byłby twoim PRAWDZIWYM kluczem, podczas gdy PK byłby tylko czymś tymczasowym, co zapewnia dobrą wydajność).
UWAGA:Najlepszym rozwiązaniem jest użycie NEWSEQUENTIALID (tak jak mówiłem w komentarzach), ale w przypadku starszej aplikacji z niewielką ilością czasu na refaktoryzację (a co gorsza, niekontrolowanie wszystkich wstawek) nie jest to możliwe.Ale rzeczywiście od 2017 r. powiedziałbym, że najlepszym rozwiązaniem jest tutaj NEWSEQUENTIALID lub robienie Guid.Comb z NHibernate.
Mam nadzieję, że to pomoże
