¿Hay algún inconveniente para confiar en la función System.Guid.NewGuid() al buscar ID únicos para los datos?

Question

Estoy buscando generar identificadores únicos para identificar algunos datos en mi sistema. Estoy usando un sistema elaborado que concatena algunos metadatos (no únicos, relevantes) con System.Guid.NewGuid() s. ¿Hay algún inconveniente en este enfoque, o estoy en claro?

Answer 1

Estoy buscando generar identificadores únicos para identificar algunos datos en mi sistema.

lo recomiendo un GUID a continuación, ya que son por definición identificadores únicos globales.

Estoy utilizando un elaborado sistema que concatena algunos metadatos (no únicos, relevantes) con System.Guid.NewGuid(). ¿Hay algún inconveniente en este enfoque, o estoy en claro?

Bueno, ya que no sabemos lo que consideraría un inconveniente, es difícil de decir. Una cantidad de posibles inconvenientes vienen a la mente:

• Los GUID son grandes: 128 bits son muchos bits.

• No se garantiza que los GUID tengan una distribución en particular; es perfectamente legal que los GUID se generen secuencialmente, y es perfectamente legal que se distribuyan uniformemente en su espacio de 124 bits (128 bits menos los cuatro bits que son el número de versión, por supuesto). Esto puede tener graves repercusiones en la base de datos el rendimiento si el GUID se utiliza como clave principal en una base de datos indexada en orden ordenado por el GUID; las inserciones son mucho más eficientes si la nueva fila siempre va al final. Un GUID distribuido uniformemente casi nunca al final.

• Versión 4 Los GUID son pseudoaleatorios pero no criptográficamente aleatorios; un atacante podría en teoría predecir cuáles son sus GUID cuando se le dé una muestra representativa de ellos. Un atacante podría, en teoría, determinar la probabilidad de que se hayan generado dos GUID en la misma sesión. Los GUID de la versión uno son, por supuesto, apenas aleatorios y le pueden decir al sofisticado lector cuándo y dónde se generaron.

• Y así sucesivamente.

Estoy planeando una serie de artículos sobre estas y otras características de los GUID en las próximas semanas; mira mi blog para más detalles.

Answer 2

Cuando usa System.Guid.NewGuid(), es posible que desee verificar que el guid no exista en su sistema.

Si bien un guid es tan complejo que es prácticamente único, no hay nada que garantice que no exista, excepto la probabilidad. Es increíblemente estadísticamente improbable, hasta el punto de que en casi todos los casos es lo mismo que ser único.

Generar guids idénticos es como ganar la lotería dos veces: no hay nada que realmente lo impida, es tan improbable que podría ser imposible.

La mayoría de las veces usted podría salirse con la suya sin verificar las coincidencias existentes, pero en un caso extremo con mucha generación pasando, o donde el sistema no debe fallar, podría valer la pena verificarlo.

EDITAR

quiero aclarar un poco más. Es muy, muy poco probable que alguna vez veas una guía duplicada. Ese es el punto. Es "globalmente único", lo que significa que existe una posibilidad tan infinitesimal de duplicar que puede suponer que será única. Sin embargo, si hablamos de un código que mantiene a una aeronave en el cielo, monitorea un reactor nuclear o maneja un soporte vital en la Estación Espacial Internacional, yo personalmente verificaría si había un duplicado, solo porque sería realmente terrible golpear esa caja de borde. Si solo está escribiendo un motor de blog, por otro lado, adelante, utilícelo sin verificarlo.

Answer 3

Siéntase libre de usar NewGuid(). No hay problema con su singularidad.

Hay muy poca probabilidad de que genere el mismo guid dos veces; un buen ejemplo se puede encontrar aquí: Simple proof that GUID is not unique

var bigHeapOGuids = new Dictionary<Guid, Guid>(); 
try 
{ 
    do 
    { 
     Guid guid = Guid.NewGuid(); 
     bigHeapOGuids.Add(guid ,guid); 
    } while (true); 
} 
catch (OutOfMemoryException) 
{ 
} 

En algún momento se acaba de estrellarse en OutOfMemory y no en conflicto de clave duplicada.