Solución:
Ventajas:
- Puede generarlos sin conexión.
- Hace que la replicación sea trivial (a diferencia de los int, lo que lo hace REALMENTE difícil)
- Los ORM suelen gustarles
- Único en todas las aplicaciones. Entonces podemos usar los PK de nuestro CMS (guid) en nuestra aplicación (también guid) y saber que NUNCA vamos a tener un conflicto.
Desventajas:
- Mayor uso de espacio, pero el espacio es más barato (más)
- No se puede realizar un 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 !? (Este punto disputado en los comentarios a continuación)
- Es más difícil realizar la depuración manual, pero no tanto.
Personalmente, los uso para la mayoría de PK en cualquier sistema de un tamaño decente, pero me “entrené” en un sistema que fue replicado por 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 llaves sustitutas suelen estar mal vistas donde alguna vez he estado trabajando. Sin embargo, SÍ usamos 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 a partir de algún campo (por ejemplo, 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 GUID PK’s: índices agrupados.
Si tiene muchos registros y un índice agrupado en un GUID, el rendimiento de su inserción será un CHUPAR, ya que obtiene inserciones en lugares aleatorios en la lista de elementos (ese es el punto), no al final (lo cual es rápido)
Entonces, si necesita insertar rendimiento, tal vez use un INT auto-inc y genere un GUID si desea compartirlo con otra persona (es decir, mostrarlo a un usuario en una URL)
@ Matt Sheppard:
Digamos que tiene una mesa de clientes. Seguramente no querrá 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 manera única al cliente y se asegura de que el identificador sea conocido por el cliente (en las facturas), de modo que el cliente y el personal de atención 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 de cliente o mediante una restricción NOT NULL + ÚNICA en la columna del identificador de cliente.
A continuación, por alguna razón (en la que no puedo pensar), se le pide 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, está preguntando por problemas futuros en toda la organización porque los GUID siempre serán únicos.
Algún “arquitecto” podría decirle que “oh, pero nosotros manejamos el verdadero restricción de unicidad del cliente en nuestro nivel de aplicación! “. Correcto. La moda con respecto a los lenguajes de programación de propósito general y (especialmente) los marcos de nivel medio cambian todo el tiempo y, por lo general, nunca sobrevivirán a su base de datos. Y hay muchas posibilidades de que en algún momento necesitará acceder a la base de datos sin pasar por la aplicación actual. == Problema. (Pero, afortunadamente, usted y el “arquitecto” se han ido hace mucho tiempo, por lo que no estará allí para limpiar el desorden). : 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 disminuya sus ambiciones de coherencia dentro del verdadero (== información no GUID).
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 puede combinar fácilmente datos de diferentes bases de datos. Estas 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.
Hay algunos problemas de rendimiento como la fragmentación de índices. 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 puede duplicar filas con diferentes GUID como claves primarias. 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 usar una clave natural y esas tienen problemas reales.