Jedinečný identifikátor (guid) jako primární klíč v návrhu databáze

128bitový GUID (uniqueidentifier ) klíč je samozřejmě 4x větší než 32bitový int klíč. Existuje však několik klíčových výhod:

• Žádný problém „IDENTITY INSERT“ při slučování obsahu
• Pokud místo NEWSEQUENTIALID() použijete hodnotu COMB, získáte časové razítko INSERT „zdarma“. Můžete dokonce SELECT z primárního klíče na základě rozsahu data/času, chcete-li, s několika efektními CAST() hovory.
• Jsou celosvětově unikátní, což se občas ukáže jako docela užitečné.
• Vzhledem k tomu, že není potřeba sledovat známky přetížení, může vaše vrstva BL přiřadit hodnotu spíše než SQL Server, čímž odpadá krok SELECT scope_identity() k získání primárního klíče po vložení.
• Pokud je jen vzdáleně možné, že byste mohli mít více než 2 miliardy záznamů, budete muset použít bigint (64 bitů) místo int . Jakmile to uděláte, uniqueidentifier je pouze dvakrát větší než bigint .
• Pomocí identifikátorů GUID je bezpečnější odhalit klíče v adresách URL atd., aniž byste se vystavili útokům typu „uhádni ID“.
• Mezi tím, jak SQL Server načítá stránky z disku, a tím, jak jsou procesory nyní většinou 64bitové, to, že číslo je 128 bitů namísto 32, neznamená, že porovnání trvá 4x déle. Poslední test, který jsem viděl, ukázal, že GUID jsou téměř stejně rychlé.
• Velikost indexu závisí na tom, kolik sloupce jsou zahrnuty. I když jsou samotné GUID větší, dalších 8 nebo 12 bajtů může být nevýznamných ve srovnání s ostatními sloupci v indexu.

Nakonec, vymáčknutí nějaké malé výhody výkonu pomocí celých čísel nemusí stát za ztrátu výhod GUID. Vyzkoušejte to empiricky a rozhodněte se sami.

Osobně stále používám obojí, v závislosti na situaci, ale rozhodujícím faktorem v mém případě nikdy nebyl výkon.