Unikalny identyfikator (guid) jako klucz podstawowy w projekcie bazy danych

128-bitowy identyfikator GUID (uniqueidentifier ) jest oczywiście 4x większy niż 32-bitowy int klucz. Istnieje jednak kilka kluczowych zalet:

• Brak problemu z „WSTAWIANIEM TOŻSAMOŚCI” podczas scalania treści
• Jeśli użyjesz wartości COMB zamiast NEWSEQUENTIALID(), otrzymasz „darmowy” znacznik czasu INSERT. Możesz nawet SELECT z klucza podstawowego na podstawie zakresu dat/godzin, jeśli chcesz, z kilkoma fantazyjnymi CAST() połączeń.
• Są unikatowe na skalę światową, co okazuje się bardzo przydatne od czasu do czasu.
• Ponieważ nie ma potrzeby śledzenia znaczników wysokiego poziomu, warstwa BL może przypisać wartość zamiast SQL Server, eliminując w ten sposób krok SELECT scope_identity() aby uzyskać klucz podstawowy po wstawieniu.
• Jeśli jest nawet możliwe, że możesz mieć więcej niż 2 miliardy rekordów, musisz użyć bigint (64 bity) zamiast int . Gdy to zrobisz, uniqueidentifier jest tylko dwa razy większy niż bigint .
• Korzystanie z identyfikatorów GUID sprawia, że ​​bezpieczniej jest ujawniać klucze w adresach URL itp. bez narażania się na ataki typu „zgadnij identyfikator”.
• Pomiędzy sposobem, w jaki SQL Server ładuje strony z dysku, a tym, jak procesory są obecnie w większości 64-bitowe, tylko dlatego, że liczba ma 128 bitów zamiast 32, nie oznacza, że ​​porównanie zajmuje 4 razy więcej czasu. Ostatni test, który widziałem, wykazał, że identyfikatory GUID są prawie tak samo szybkie.
• Rozmiar indeksu zależy od ile kolumny są uwzględnione. Nawet jeśli same identyfikatory GUID są większe, dodatkowe 8 lub 12 bajtów może być nieistotne w porównaniu z innymi kolumnami w indeksie.

W końcu wyciśnięcie niewielkiej przewagi wydajności za pomocą liczb całkowitych może nie być warte utraty zalet identyfikatora GUID. Przetestuj to empirycznie i zdecyduj sam.

Osobiście nadal używam obu, w zależności od sytuacji, ale w moim przypadku czynnikiem decydującym nigdy nie była wydajność.