Ventajas y desventajas de las claves de base de datos GUID/UUID

Question

He trabajado en varios sistemas de bases de datos en el pasado donde mover entradas entre bases de datos habría sido mucho más fácil si todas las claves de la base de datos hubieran sido GUID/UUID valores.He considerado seguir este camino varias veces, pero siempre hay un poco de incertidumbre, especialmente en torno al rendimiento y las URL que no se pueden leer por teléfono.

¿Alguien ha trabajado extensamente con GUID en una base de datos?¿Qué ventajas obtendría si siguiera ese camino y cuáles son los posibles riesgos?

Answer 1

Ventajas:

• Puede generarlos sin conexión.
• Hace que la replicación sea trivial (a diferencia de la de int, lo que la hace REALMENTE difícil)
• A los ORM generalmente les gustan
• Único en todas las aplicaciones.Entonces podemos usar las PK de nuestro CMS (guid) en nuestra aplicación (también guid) y saber que NUNCA tendremos un conflicto.

Desventajas:

• Mayor uso del espacio, pero el espacio es más barato (más)
• No se puede realizar el pedido por ID para obtener el pedido de inserción.
• Puede verse feo en una URL, pero en realidad, ¿qué estás haciendo poniendo una clave de base de datos REAL en una URL?
• Es más difícil realizar una depuración manual, pero no tanto.

Personalmente, los uso para la mayoría de las PK en cualquier sistema de tamaño decente, pero me "entrené" en un sistema que se replicaba en todas partes, así que TENÍAMOS que tenerlos.YMMV.

Creo que lo de los datos duplicados es una tontería: puedes obtener datos duplicados como sea que lo hagas.Las claves sustitutas suelen estar mal vistas dondequiera que haya estado trabajando.Sin embargo, SÍ utilizamos el sistema similar a WordPress:

• ID único para la fila (GUID/lo que sea).Nunca visible para el usuario.
• La identificación pública se genera UNA VEZ desde algún campo (p. ej.el título - conviértalo en el título-del-artículo)

ACTUALIZAR:Así que este recibe mucho +1, y pensé que debería señalar una gran desventaja de los GUID PK:Índices agrupados.

Si tiene muchos registros y un índice agrupado en un GUID, el rendimiento de su inserción será SUCK, ya que obtendrá inserciones en lugares aleatorios en la lista de elementos (ese es el punto), no al final (lo cual es rápido).

Entonces, si necesita rendimiento de inserción, tal vez use un INT de inclusión automática y genere un GUID si desea compartirlo con otra persona (es decir, mostrárselo a un usuario en una URL)

Answer 2

@Matt Sheppard:

Digamos que tienes una mesa de clientes.Seguramente no desea que un cliente exista en la tabla más de una vez, o se producirá mucha confusión en sus departamentos de ventas y logística (especialmente si las múltiples filas sobre el cliente contienen información diferente).

Por lo tanto, tiene un identificador de cliente que identifica de forma única al cliente y se asegura de que el cliente conozca el identificador (en las facturas), de modo que el cliente y el personal de servicio al cliente tengan una referencia común en caso de que necesiten comunicarse.Para garantizar que no haya registros de clientes duplicados, agregue una restricción de unicidad a la tabla, ya sea a través de una clave principal en el identificador del cliente o mediante una restricción NOT NULL + UNIQUE en la columna del identificador del cliente.

A continuación, por alguna razón (que no se me ocurre), se le solicita que agregue una columna GUID a la tabla de clientes y la convierta en la clave principal.Si la columna de identificador de cliente ahora se deja sin una garantía de unicidad, estará generando problemas futuros en toda la organización porque los GUID siempre serán únicos.

Algún "arquitecto" podría decirte que "oh, pero nosotros nos encargamos del real ¡restricción de unicidad del cliente en nuestro nivel de aplicación!".Bien.La moda con respecto a los lenguajes de programación de propósito general y (especialmente) los marcos de nivel medio cambia todo el tiempo y, por lo general, nunca sobrevivirá a su base de datos.Y existe una gran posibilidad de que en algún momento necesite acceder a la base de datos sin pasar por la presente aplicación.== Problema.(Pero afortunadamente, usted y el "arquitecto" se fueron hace mucho tiempo, por lo que no estará allí para limpiar el desorden). En otras palabras:Mantenga restricciones obvias en la base de datos (y también en otros niveles, si tiene tiempo).

En otras palabras:Puede haber buenas razones para agregar columnas GUID a las tablas, pero no caiga en la tentación de hacer que eso reduzca sus ambiciones de coherencia dentro del real (==información no GUID).

Answer 3

Las principales ventajas son que puede crear identificaciones únicas sin conectarse a la base de datos.Y las identificaciones son únicas a nivel mundial, por lo que puedes combinar fácilmente datos de diferentes bases de datos.Parecen pequeñas ventajas pero me han ahorrado mucho trabajo en el pasado.

Las principales desventajas son que se necesita un poco más de almacenamiento (no es un problema en los sistemas modernos) y las identificaciones no son realmente legibles por humanos.Esto puede ser un problema al depurar.

Existen algunos problemas de rendimiento como la fragmentación del índice.Pero esos son fácilmente solucionables (guías de peine de jimmy nillson: http://www.informit.com/articles/article.aspx?p=25862 )

Editar fusioné mis dos respuestas a esta pregunta

@Matt Sheppard Creo que quiere decir que puedes duplicar filas con diferentes GUID como claves principales.Este es un problema con cualquier tipo de clave sustituta, no solo con los GUID.Y como dijo, se resuelve fácilmente agregando restricciones únicas significativas a las columnas que no son clave.La alternativa es utilizar una clave natural y esas tienen problemas reales.

Answer 4

Los GUID pueden causarle muchos problemas en el futuro si se utilizan como "uniqificadores", permitiendo que datos duplicados entren en sus tablas.Si desea utilizar GUID, considere seguir manteniendo restricciones ÚNICAS en otras columnas.

Answer 5

¿Por qué nadie menciona el rendimiento?Cuando tienes múltiples uniones, todas basadas en estos desagradables GUID, el rendimiento se irá por los suelos, he estado ahí :(

Answer 6

Otro pequeño problema a considerar con el uso de GUIDS como claves principales si también usa esa columna como índice agrupado (una práctica relativamente común).Recibirá un impacto al insertar debido a la naturaleza de una guía que no comienza de manera secuencial de ninguna manera, por lo que habrá divisiones de página, etc. cuando inserte.Sólo algo a considerar si el sistema va a tener un IO alto...

Answer 7

claves-primarias-ids-versus-guids

El costo de los GUID como claves primarias (Servidor SQL 2000)

Mitos, GUID vs.Autoincremento (MySQL5)

Esto es realmente lo que quieres.

Ventajas de UID

• Único en cada tabla, cada base de datos, cada servidor
• Permite fusionar fácilmente registros de diferentes bases de datos
• Permite una fácil distribución de bases de datos entre múltiples servidores.
• Puede generar identificaciones en cualquier lugar, en lugar de tener que ir de ida y vuelta a la base de datos.
• La mayoría de los escenarios de replicación requieren columnas GUID de todos modos

Contras del GUID

• Es nada menos que 4 veces mayor que el valor de índice tradicional de 4 bytes;Esto puede tener graves implicaciones en el rendimiento y el almacenamiento si no se tiene cuidado.
• Engorroso de depurar (donde userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
• Los GUID generados deben ser parcialmente secuenciales para lograr un mejor rendimiento (por ejemplo, newequentialid() en SQL 2005) y para permitir el uso de índices agrupados.

Answer 8

Hay una cosa que no se aborda realmente, es decir, el uso aleatorio (UUIDv4) Los ID como claves principales perjudicarán el rendimiento del índice de clave primaria.Sucederá independientemente de que su tabla esté agrupada alrededor de la clave o no.

Los RDBM generalmente garantizan la unicidad de las claves primarias y garantizan las búsquedas mediante una clave, en una estructura llamada BTree, que es un árbol de búsqueda con un factor de ramificación grande (un árbol de búsqueda binario tiene un factor de ramificación de 2).Ahora, un ID entero secuencial provocaría que las inserciones se produzcan justo uno lado del árbol, dejando intactos la mayoría de los nudos de las hojas.Agregar UUID aleatorios hará que las inserciones dividan los nodos de hoja en todo el índice.

Del mismo modo, si los datos almacenados son en su mayoría temporales, a menudo ocurre que es necesario acceder a los datos más recientes y combinarlos con los más recientes.Con UUID aleatorios, los patrones no se beneficiarán de esto y alcanzarán más filas de índice, por lo que necesitarán más páginas de índice en la memoria.Con ID secuenciales, si los datos más recientes son los más necesarios, las páginas de índice activas requerirían menos RAM.