GUID vs INT IDENTITY

Question

Eventuali duplicati:
How do you like your primary keys?

Sono consapevoli dei vantaggi di utilizzare un GUID, così come i vantaggi di utilizzare e INT come PK in un database. Considerando che un GUID è essenzialmente INT a 128 bit e INT normale a 32 bit, INT è un risparmiatore di spazio (sebbene questo punto sia generalmente discutibile nella maggior parte dei sistemi moderni).

Alla fine, in quali circostanze ti vedresti utilizzare un INT come PK rispetto a un GUID?

Answer 1

Kimberley Tripp (SQLSkills.com) ha an article sull'utilizzo di GUID come chiavi primarie. Lei consiglia contro di esso a causa del sovraccarico inutile.

Answer 2

Un INT è sicuramente molto più facile da leggere durante il debug e molto più piccolo.

Vorrei, tuttavia, utilizzare un GUID o simile come chiave di licenza per un prodotto. Sai che sarà unico, e sai che non sarà sequenziale.

Answer 3

Quando si confrontano valori come la relazione chiave Primaria con quella esterna, INT sarà più veloce. Se le tabelle sono indicizzate correttamente e le tabelle sono piccole, potresti non vedere molto rallentamenti, ma dovresti provarlo per essere sicuro. Gli INT sono anche più facili da leggere e comunicare con altre persone. È molto più semplice dire: "Puoi guardare il record 1234?" invece di "Puoi guardare il record 031E9502-E283-4F87-9049-CE0E5C76B658?"

Answer 4

Alcuni SO non generano più GUID basati su caratteristiche hardware univoche (CPUID, MAC) perché rendono gli utenti facili da tracciare (problemi di privacy). Ciò significa che l'unicità del GUID spesso non è più così universale come molti pensano.

Se si utilizza una funzione di identificazione automatica del database, il database potrebbe in teoria essere assolutamente sicuro che non vi sia alcuna duplicazione.

Answer 5

Penso sempre che PK dovrebbe essere numerico dove possibile. Non dimenticare di avere GUID come PK significherà probabilmente che sono usati anche in altre tabelle come chiavi esterne, quindi paging e index ecc saranno maggiori.

Answer 6

Penso che anche il database sia importante. Da una prospettiva MySQL - generalmente, più piccolo è il datatype più veloce è la performance.

Sembra valere per int vs GUID troppo - http://kccoder.com/mysql/uuid-vs-int-insert-performance/

Answer 7

userei GUID come PK solo se questo tasto limiti di valore simile. Ad esempio, l'id utente (gli utenti in WinNT sono descritti con GUID) o l'id del gruppo utente. Un altro esempio. Se sviluppi un sistema distribuito per la gestione dei documenti e diverse parti del sistema in diversi luoghi in tutto il mondo puoi creare alcuni documenti. In tal caso, utilizzerei GUID, perché garantisce che 2 documenti creati in diverse parti del sistema distribuito non abbiano lo stesso ID.

Answer 8

Per rispondere alla tua domanda: Alla fine, in quali circostanze ti vedresti utilizzare un INT come PK rispetto a un GUID?

Vorrei utilizzare un GUID se il mio sistema avesse una versione online/offline che all'interno della versione offline è possibile salvare i dati e che i dati vengono trasferiti sul server un giorno durante una sincronizzazione.In questo modo, sei sicuro di non avere la stessa chiave due volte all'interno del tuo database.

Answer 9

Se i dati risiedono in un singolo database (come la maggior parte dei dati per le applicazioni che scriviamo in generale), quindi utilizzo uno IDENTITY. È facile, pensato per essere usato in questo modo, non frammenta l'indice cluster ed è più che sufficiente. Avrai esaurito lo spazio a 2 miliardi di dischi (circa 4 miliardi se utilizzi valori negativi), ma verrai comunque tostato se tu avessi tanti record in una tabella, e poi avrai un problema di data warehousing.

Se i dati sono presenti in più database o interfacce indipendenti con un servizio di terze parti, utilizzerò lo GUID probabilmente già generato. Un buon esempio potrebbe essere una tabella UserProfiles nel database che associa gli utenti in Active Directory ai loro profili utente nell'applicazione tramite il loro objectGUID assegnato ad Active Directory.

Answer 10

INT è un risparmio di spazio (anche se questo punto è generalmente discutibile nella maggior parte dei moderni sistemi ).

Non così. Può sembrare così a prima vista, ma si noti che la chiave primaria di ogni tabella verrà ripetuta più volte nel database negli indici e come chiave esterna in altre tabelle. E sarà coinvolto in quasi tutte le query contenenti la sua tabella - e molto intensamente quando si tratta di una chiave esterna utilizzata per un join.

Inoltre, ricorda che le CPU moderne sono molto, molto veloci, ma le velocità della RAM non sono state mantenute. Il comportamento della cache diventa quindi sempre più importante. E il modo migliore per ottenere un buon comportamento della cache è avere insiemi di dati più piccoli. Quindi la differenza apparentemente irrilevante tra 4 e 16 byte potrebbe portare a una notevole differenza di velocità. Non necessariamente sempre - ma è qualcosa da considerare.

Answer 11

Se si pianifica di unire il database a un certo punto, ad esempio per un'impostazione di tipo di replica su più siti, Guid's risparmierà molto dolore. Ma a parte questo, trovo che Int sia più facile.

Answer 12

Oltre ad essere una scelta sbagliata quando è necessario sincronizzare diverse istanze di database, INT ha uno svantaggio che non ho visto menzionato: gli inserimenti si verificano sempre a un'estremità dell'albero dell'indice. Ciò aumenta la contesa del blocco quando si dispone di una tabella con molto movimento (poiché le stesse pagine indice devono essere modificate da inserimenti simultanei, mentre i GUID saranno inseriti in tutto l'indice). L'indice può anche essere ribilanciato più spesso se si utilizza un albero B * o una struttura dati simile.

Ovviamente, gli int sono più facili da guardare quando eseguono query manuali e segnalano la costruzione, e il consumo di spazio può aumentare con gli usi FK.

Sarei interessato a vedere qualsiasi misura di quanto bene ad es. SQL Server gestisce effettivamente le tabelle con inserimento pesante con IDENTITY PK.

Answer 13

Abbiamo Guid nel nostro software aziendale molto complesso ovunque. Funziona senza intoppi.

Credo che i Guids siano semanticamente più adatti a fungere da identificatori. Non c'è motivo di preoccuparsi inutilmente delle prestazioni finché non si è di fronte a questo problema. Attenti all'ottimizzazione prematura.

C'è anche un vantaggio con la migrazione del database di qualsiasi tipo. Con Guids non avrai collisioni. Se si tenta di unire più DB in cui vengono utilizzati i nomi per identità, è necessario sostituire i loro valori. Se questi vecchi valori sono stati utilizzati negli URL, ora saranno diversi in seguito al successo SEO.