GUID vs INT IDENTITY [duplicato]

Question

  

Possibile duplicato:
   Come ti piacciono le tue chiavi primarie?

Sono a conoscenza dei vantaggi dell'utilizzo di un GUID, nonché dei vantaggi dell'utilizzo di INT e di un PK in un database. Considerando che un GUID è essenzialmente un INT a 128 bit e un 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 usare un INT come PK contro un GUID?

Answer 1

Kimberley Tripp (SQLSkills.com) ha un articolo sull'uso dei GUID come chiavi primarie. Lei sconsiglia a causa del sovraccarico inutile.

Answer 2

Oltre ad essere una scelta sbagliata quando è necessario sincronizzare diverse istanze di database, gli INT hanno uno svantaggio che non ho mai visto menzionato: gli inserimenti si verificano sempre a un'estremità dell'albero dell'indice. Ciò aumenta la contesa tra blocchi quando si dispone di una tabella con molti movimenti (poiché le stesse pagine dell'indice devono essere modificate da inserimenti simultanei, mentre i GUID verranno inseriti in tutto l'indice). Potrebbe essere necessario ribilanciare l'indice più spesso se si utilizza un albero B * o una struttura dati simile.

Ovviamente, gli int sono più facili da vedere quando si eseguono query manuali e segnalano la costruzione, e il consumo di spazio può sommarsi attraverso gli usi FK.

Sarei interessato a vedere qualsiasi misura di come ad es. SQL Server in realtà gestisce tabelle con inserti pesanti con IDENTITY PK.

Answer 3

Per rispondere alla tua domanda: Alla fine, in quali circostanze ti vedresti usare un INT come PK contro 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 al server un giorno durante una sincronizzazione. In questo modo, sei sicuro di non avere la stessa chiave due volte nel tuo database.

Answer 4

  

INT è un salvaspazio (anche se questo   il punto è generalmente discutibile nella maggior parte dei moderni   sistemi).

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

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

Answer 5

Abbiamo guide nel nostro software aziendale molto complesso ovunque. Funziona senza problemi.

Credo che le guide siano semanticamente più adatte a fungere da identificatori. Inoltre, non ha senso preoccuparsi inutilmente delle prestazioni fino a quando non si incontra questo problema. Attenzione 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 ints per l'identità, è necessario sostituire i loro valori. Se questi vecchi valori sono stati utilizzati negli URL, ora saranno diversi dopo il successo SEO.

Answer 6

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

Answer 7

Alcuni sistemi operativi non generano più GUID basati su caratteristiche hardware uniche (CPUID, MAC) perché hanno semplificato la tracciabilità degli utenti (problemi di privacy). Ciò significa che l'unicità GUID spesso non è più universale come molti pensano.

Se si utilizza una funzione auto-id del proprio database, il database potrebbe in teoria assicurarsi assolutamente che non vi siano duplicazioni.

Answer 8

Se i dati vivono in un unico database (come la maggior parte dei dati per le applicazioni che scriviamo in generale), allora uso un IDENTITY . È facile, destinato ad essere utilizzato in questo modo, non frammenta l'indice cluster ed è più che sufficiente. Sarai a corto di spazio a 2 miliardi di record (~ 4 miliardi se utilizzi valori negativi), ma saresti comunque brindisi se avessi tanti record in una tabella e quindi avessi un problema di archiviazione dei dati.

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

Answer 9

Se stai pianificando di unire il database ad un certo punto, cioè per una configurazione del tipo di replica multi-sito, Guid's risparmierà molto dolore. Ma a parte questo, trovo che Int è più facile.

Answer 10

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

Answer 11

Penso che anche il database sia importante. Dal punto di vista di MySQL, in genere più piccolo è il tipo di dati, più veloci saranno le prestazioni.

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

Answer 12

Vorrei usare GUID come PK solo se questa chiave si collega a un valore simile. Ad esempio, ID utente (gli utenti in WinNT sono descritti con GUID) o ID gruppo utenti. Un altro esempio. Se si sviluppa un sistema distribuito per la gestione dei documenti e diverse parti del sistema in luoghi diversi in tutto il mondo, è possibile creare alcuni documenti. In tal caso, utilizzerei il GUID, perché garantisce che 2 documenti creati in diverse parti del sistema distribuito non avrebbero lo stesso ID.

Answer 13

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.