V mé práci používáme UUID jako PK. Z vlastní zkušenosti vám mohu říci, NEPOUŽÍVEJTE JE jako PK (mimochodem SQL Server).
Je to jedna z věcí, které když máte méně než 1000 záznamů, je to v pořádku, ale když máte miliony, je to to nejhorší, co můžete udělat. Proč? Protože UUID nejsou sekvenční, takže pokaždé, když je vložen nový záznam, MSSQL se musí podívat na správnou stránku, kam záznam vložit, a poté záznam vložit. Skutečně ošklivým důsledkem toho je, že všechny stránky končí v různých velikostech a nakonec jsou fragmentované, takže nyní musíme pravidelně provádět defragmentaci.
Když použijete automatický přírůstek, MSSQL vždy přejde na poslední stránku a vy skončíte se stejně velkými stránkami (teoreticky), takže výkon při výběru těchto záznamů je mnohem lepší (také proto, že INSERTy nebudou blokovat tabulku/stránku pro tak dlouho).
Velkou výhodou použití UUID jako PK je však to, že pokud máme clustery DB, nedojde ke konfliktům při slučování.
Doporučil bych následující model:1. PK INT Identita2. Další sloupec automaticky vygenerován jako UUID.
Tímto způsobem je proces sloučení možný (UUID by byl váš skutečný klíč, zatímco PK by bylo jen něco dočasného, co vám poskytne dobrý výkon).
POZNÁMKA:Nejlepším řešením je použít NEWSEQUENTIALID (jak jsem říkal v komentářích), ale pro starší aplikaci, která nemá moc času na refaktorování (a co je horší, neovládá všechny vložky), to není možné. od roku 2017 bych řekl, že nejlepším řešením je NEWSEQUENTIALID nebo použití Guid.Comb s NHibernate.
Doufám, že to pomůže