Tipo di dati più efficiente per UUID nel database oltre a UUID nativo

Question

Quale sarebbe il tipo di dati più efficiente per archiviare un UUID / GUID in database che non hanno un tipo di dati UUID / GUID nativo? 2 GRANDI?

E quale sarebbe il codice più efficiente (preferibilmente C #) da convertire in e da un GUID a quel tipo?

Grazie.

Answer 1

È difficile dire quale sarebbe il più efficiente senza conoscere il database che si sta utilizzando.

La mia prima inclinazione sarebbe quella di utilizzare una colonna binaria (16) .

Per quanto riguarda l'utilizzo di quel valore in C #, il tipo System.Guid ha un costruttore che accetta un array byte [] e un metodo ToByteArray () che restituisce un array di byte.

Answer 2

Nella mia esperienza, l'UUID suddiviso in due numeri interi sarà ancora più efficiente rispetto all'utilizzo di un campo char. DB diversi reagiscono in modi diversi però. Anche la collazione potrebbe fare la differenza. Detto questo, di solito ci sono prestazioni molto più grandi "peccati". in tutte le applicazioni e non credo che questa sarebbe una cosa importante in entrambi i modi per molte applicazioni. Dovrai giudicarti in base a quanto sarà impegnata questa parte della tua app? Hai bisogno dell'interrogazione più veloce in assoluto possibilmente da UUID? 600 ns contro 400 nn fa una grande differenza temporale per te?

Se ci sarà un sacco di sql manuale fatto con il db, allora avere una chiave che comprende un UUID da campi separati tipo di puzza quando devi fare un inserimento e non c'è alcun valore predefinito di db per esso. Questo è anche un problema con i caratteri.

Se disponi di un livello di astrazione del database, la combinazione di più campi di tabella per ottenere il tuo UUID non dovrebbe essere un grosso problema.

Answer 3

Guardando la .NET guid class , ci sono un paio di modi per inizializzare un guid:

Guid (Int32, Int16, Int16, Byte, Byte, Byte, Byte, Byte, Byte, Byte, Byte) Guid (string)

Sebbene possa essere più efficiente, in teoria, memorizzare l'intero in un database (è possibile utilizzare lo spostamento dei bit per memorizzare realmente 4 numeri interi a 32 bit .. ma dovresti calcolarlo durante il caricamento e il salvataggio di ogni Inoltre, occorrerebbero 4 campi nel database .. Immagino che finirebbe per essere meno efficiente.

Aggiungete l'impossibilità di leggerlo direttamente nel vostro database per scopi di debug / test, e direi a mani basse che è meglio archiviare una stringa. È solo un campo di 32 caratteri (36 se includi i trattini) ed è molto facile da convertire. guid. ToString () e new Guid (stringValue);