Un GUID a 128 bit (uniqueidentifier ) è ovviamente 4 volte più grande di un int a 32 bit chiave. Tuttavia, ci sono alcuni vantaggi chiave:
- Nessun problema di "INSERTO IDENTITÀ" durante l'unione di contenuti
- Se usi un valore COMB invece di NEWSEQUENTIALID(), ottieni un timestamp INSERT "gratuito". Puoi anche
SELECTdalla chiave primaria in base a un intervallo di data/ora se lo desideri con alcuniCAST()fantasiosi chiamate. - Sono unici a livello globale, il che si rivela molto utile di tanto in tanto.
- Dato che non c'è bisogno di tenere traccia degli high-water mark, il tuo livello BL può assegnare il valore anziché SQL Server, eliminando così il passaggio di
SELECT scope_identity()per ottenere la chiave primaria dopo un inserimento. - Se è anche lontanamente possibile che tu possa avere più di 2 miliardi di record, dovrai utilizzare
bigint(64 bit) invece diint. Dopo averlo fatto,uniqueidentifierè solo il doppio di unbigint. - L'utilizzo dei GUID rende più sicuro esporre le chiavi negli URL e così via senza esporsi ad attacchi "indovina l'ID".
- Tra il modo in cui SQL Server carica le pagine dal disco e il modo in cui i processori ora sono principalmente a 64 bit, solo perché un numero è 128 bit anziché 32 non significa che il confronto richiede 4 volte più tempo. L'ultimo test che ho visto ha mostrato che i GUID sono quasi altrettanto veloci.
- La dimensione dell'indice dipende da quanti le colonne sono incluse. Anche se i GUID stessi sono più grandi, gli 8 o 12 byte in più potrebbero essere insignificanti rispetto alle altre colonne nell'indice.
Alla fine, ridurre alcuni piccoli vantaggi in termini di prestazioni utilizzando numeri interi potrebbe non valere la pena perdere i vantaggi di un GUID. Testalo empiricamente e decidi tu stesso.
Personalmente, uso ancora entrambi, a seconda della situazione, ma nel mio caso il fattore decisivo non è mai stato la performance.
