it-swarm.it

Guid vs INT - Quale è meglio come chiave primaria?

Sto leggendo i motivi per usare Guid e int.

int è più piccolo, più veloce, facile da ricordare, mantiene una sequenza cronologica. E per quanto riguarda Guid, l'unico vantaggio che ho riscontrato è che è unico. Nel qual caso un Guid sarebbe migliore di e int e perché?

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

Perché esattamente è stato creato Guid? 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 usa Guid per qualcosa?)

(Guid = UniqueIdentifier) ​​tipo su SQL Server

107
BrunoLM

Questo è stato chiesto in Stack Overflow qui e qui .

post di Jeff spiega molte cose su pro e contro dell'utilizzo di 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 GUID colonne comunque

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
  • Ingombrante da eseguire il debug (where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
  • I GUID generati dovrebbero essere parzialmente sequenziali per le migliori prestazioni (ad es. 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 int e impostarlo con incremento automatico ( seed identità in SQL Server ).

94
CoderHawk

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

19
TML

Ho usato un approccio ibrido con successo. Le tabelle contengono ENTRAMBI una colonna di chiave primaria a incremento automatico id E una colonna guid. guid può essere utilizzato secondo necessità per identificare in modo univoco la riga a livello globale e id può essere utilizzato per query, ordinamento e identificazione umana della riga.

18
rmirabelle

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. Quando 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 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.

1
Alpha

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

1
golopot

@rmirrabelle rispondi sopra - https://dba.stackexchange.com/a/96990/118371 è quello che faccio. Tuttavia, per progetti su larga scala, esiste un design eccezionale.

Usa: una tabella di mappatura dei tasti

TableA

- ID int (PK)
- Data varchar(100)

TableAMap

- ID int (PK)
- UniversalID GUID (Indexed - nonclustered)

Come altri hanno discusso in questo thread, raramente i GUID sono necessari per la replica/importazione/exprt del database. Quindi, invece di avere il GUID nella tabella principale, dove occupa un ulteriore 8 byte per riga e dove un GUID sarà ( per impostazione predefinita) memorizzato sullo stesso volume; una tabella separata (ovvero la normalizzazione) viene in soccorso.

Con una tabella separata, i tuoi DBA sono liberi di archiviarlo su un altro disco più lento. Inoltre, se il GUID è necessario SOLO per determinati processi batch, è possibile creare l'indice GUID appena prima che sia necessario, quindi rilasciarlo dopo.

0
Todd

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 di NIC viene utilizzato come parte dell'algoritmo GUID. Se a NIC è sostituito, non vi è alcuna garanzia che l'UID sarà 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 di valori usando l'algoritmo.

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

0
bobo8734