Guid vs INT - Quale è meglio come chiave primaria?

Sto leggendo i motivi per usare o meno Guide int.

intè più piccolo, più veloce, facile da ricordare, mantiene una sequenza cronologica. E per quanto riguarda Guid, l'unico vantaggio che ho trovato è che è unico. Nel qual caso a Guidsarebbe meglio di e inte perché?

Da quanto ho visto, intnon ha difetti se non per il limite numerico, che in molti casi è irrilevante.

Perché è stato Guidcreato esattamente ? In realtà penso che abbia uno scopo diverso da quello di servire come chiave primaria di una semplice tabella. (Qualche esempio di un'applicazione reale che utilizza Guidqualcosa?)

_{(Guid = UniqueIdentifier) ​​tipo su SQL Server}

Questo è stato chiesto in Stack Overflow qui e qui .

Il post di Jeff spiega molto sui pro e contro dell'utilizzo del GUID.

GUID Pro

• Unico su ogni tabella, ogni database e ogni server
• Consente una facile fusione di record da diversi database
• Consente una facile distribuzione di database su più server
• È possibile generare ID ovunque, invece di dover andare di andata e ritorno nel database
• La maggior parte degli scenari di replica richiede comunque colonne GUID

GUID Cons

• È enorme 4 volte più grande del tradizionale valore dell'indice a 4 byte; questo può avere gravi conseguenze in termini di prestazioni e archiviazione se non stai attento
• Da ingombrante a debug ( where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
• I GUID generati dovrebbero essere parzialmente sequenziali per le migliori prestazioni (ad esempio, newsequentialid()su SQL Server 2005+) e per consentire l'uso di indici cluster

Se si è certi delle prestazioni e non si prevede di replicare o unire i record, utilizzare inte impostare l'incremento automatico ( seed di identità in SQL Server ).

Se stai sincronizzando i tuoi dati con una fonte esterna, un GUID persistente può essere molto meglio. Un rapido esempio di dove stiamo usando un GUID è uno strumento che viene inviato al cliente per eseguire la scansione della propria rete ed eseguire determinate classi di rilevamento automatico, archiviare i record trovati e quindi tutti i record dei clienti sono integrati in un database centrale di nuovo dalla nostra parte. Se usassimo un numero intero, avremmo 7.398 "1" s, e sarebbe molto più difficile tenere traccia di quale "1" era quale.

Ho usato un approccio ibrido con successo. Le tabelle contengono ENTRAMBI una idcolonna intera di chiave primaria con incremento automatico E una guidcolonna. Il guidpuò essere usato come necessario globalmente univoco identificare la riga e idpuò essere utilizzato per le query, selezione e identificazione umana della fila.

Alcune best practice là fuori menzionano ancora che dovresti usare un tipo di dati che accolga con meno memoria possibile l'intero insieme di valori che userai. Ad esempio, se lo si utilizza per memorizzare il numero di datori di lavoro in una piccola impresa e è improbabile che arrivi a 100, nessuno suggerirebbe di utilizzare un valore bigint mentre int (anche smallint) lo farebbe.

Naturalmente, lo svantaggio di questo è come "Di 'no alla scalabilità!"

Inoltre, so che questo non è totalmente correlato, ma c'è un altro fattore al riguardo. Se non eccessivo, di solito provo a raccomandare di utilizzare una chiave primaria non generata automaticamente, se ha senso. Ad esempio, se stai salvando le informazioni del conducente, non preoccuparti di creare una nuova colonna generata automaticamente per "ID", basta usare il numero di licenza.

So che questo sembra davvero ovvio, ma vedo che l'essere dimenticato abbastanza spesso.

Per il contesto: questa parte della risposta è stata indirizzata da un approccio teorico dei dati, in cui si desidera che il proprio PK sia l'identificatore univoco dei dati per un record. Il più delle volte li creiamo quando esistono già, da cui la risposta precedente.

Tuttavia, è molto raro che tu possa avere uno stretto controllo su questi punti dati e, in quanto tale, potrebbe essere necessario apportare correzioni o aggiustamenti. Non puoi farlo con le chiavi primarie (beh, puoi, ma può essere una seccatura).

Grazie @VahiD per i chiarimenti.

L'uso degli ID di incremento automatico potrebbe contenere informazioni sull'attività aziendale. Se gestisci un negozio e utilizzi order_idper identificare pubblicamente un acquisto, allora chiunque può scoprire il tuo numero mensile di vendite con una semplice aritmetica.

Un'altra cosa su come vengono generati i GUID. mrdenny ha giustamente sottolineato che anche se si utilizza newsequentialid (), il riavvio delle istanze fa sì che i nuovi valori inizino con i "buchi" lasciati indietro nell'elaborazione precedente. Un'altra cosa che influenza i GUID "sequenziali" è la scheda di rete. Se ricordo bene, l'UID della NIC viene utilizzato come parte dell'algoritmo GUID. Se viene sostituita una scheda NIC, non esiste alcuna garanzia che l'UID avrà un valore più elevato per mantenere l'aspetto sequenziale delle cose. Inoltre, non sono sicuro di come più schede di rete possano influenzare l'assegnazione dei valori utilizzando l'algoritmo.

Solo un pensiero e spero di ricordare correttamente. Vi auguro una buona giornata!

Utilizza entrambi

Utilizzare int / Bigint per la chiave primaria in quanto è facile da mantenere e utilizzare come relazioni di chiave esterna.

Ma associare una colonna al GUID in modo che ogni riga abbia anche una colonna univoca