Uso de un GUID y un entero de incremento automático

Question

He estado investigando el uso de GUID como claves principales en las bases de datos. Hasta ahora, los profesionales parecen superar los inconvenientes. Sin embargo, veo un punto en el que los GUID pueden no ser lo que quiero.

En mi aplicación, los usuarios deberían ser capaces de identificar objetos basados ​​en una identificación fácil de usar. Entonces, por ejemplo, si quieren obtener un producto específico sin escribir el nombre completo, pueden usar la identificación del producto. Los GUID no son fáciles de recordar por algo así.

La solución en la que he estado pensando es utilizar tanto un GUID como un entero de incremento automático. El GUID sería la clave primaria de la fila, mientras que el entero de incremento automático sería un índice utilizado por las funciones de filtrado de la aplicación. Sin embargo, todas las sentencias SQL SELECT, UPDATE, DELETE usarían el GUID.

La razón principal por la que deseo utilizar los GUID es para evitar conflictos al fusionar dos bases de datos. Si la Base de datos n. ° 1 y la Base de datos n. ° 2 tienen un Producto n. ° 2, la secuencia de comandos del importador debería cambiar la Id. Y todas las claves foráneas que se refieren a ella. Con los GUID, solo tengo que cambiar el ID fácil de usar en la tabla, mientras que las claves externas usarían el GUID exclusivo para cada registro importado y, por lo tanto, funcionarán sin modificaciones.

Entonces, mi pregunta es: ¿hay algún problema importante (además del tamaño del campo GUID y la fragmentación de página fácil) con un índice entero autoincrementable y una clave principal GUID?

Answer 1

Siempre tiendo a utilizar claves primarias sustitutas en mi base de datos. Es decir: esas claves primarias no tienen ningún significado real en el dominio del problema, y ​​por lo tanto, esas claves primarias nunca se exponen a los usuarios. (Si esta clave primaria sustituta es de tipo GUID o una identidad, no me importa, esto depende de los requisitos).

Si dices que los usuarios deberían ser capaces de identificar objetos basados ​​en una identificación fácil de usar, entonces, creo que este ID fácil de usar es un valor que pertenece a tu 'dominio problemático'. Esto significa que esta ID debe ser un atributo en su tabla, pero no debe usarse como clave principal en su tabla.

Esto también le permite modificar fácilmente el valor de una ID fácil de usar (si fuera necesario), sin tener que preocuparse también de modificar las claves externas relacionadas.

Answer 2

En MySQL, tendrá que configurar su numérico ID como PRIMARY KEY, como AUTO_INCREMENT puede ser sólo el PRIMARY KEY, lo que significa que también debe ser NOT NULL.

Todavía se puede definir un UNIQUE INDEX en su columna GUID y utilizarlo en cualquier lugar, aunque una mesa InnoDB se agruparán en el id numérico, no en el GUID.

Answer 3

Existe una escuela de pensamiento que dice que nunca deberías exponer tus ID sustitutos al mundo exterior. Entonces dirían si quieres una identificación comercial, deberías usar algo más para eso.

This Wikipedia article, por ejemplo, dice esto:

Disociación

Los valores de las claves sustitutas generados - ya que son generados y arbitraria - no tienen relación con el significado en el mundo real de la datos celebrados en una fila. Al inspeccionar otra fila que contiene una clave externa, haga referencia a una clave sustituta, no es posible determinar el significado de que tenga esa referencia simplemente mirando los datos en la fila misma. Se ha agregado una capa a esta direccionamiento indirecto para cada unión de clave foránea que uno debe navegar mientras intenta hacer sentido de un elemento de datos. Esto también puede hacer que auditoría más difícil, como datos incorrectos no es obvio en la inspección .

Las claves sustitutas tampoco son naturales para los datos que se exportan y comparten. Una dificultad particular es que dos instancias de un esquema pueden mantener registros lo que significa, lógicamente, lo mismo (es decir - que son los mismos en un sentido negocio), pero que tienen una clave diferente debido a la historia de cómo se asignaron las claves. Un enfoque para tratar con esto es adoptar la regla de que las claves sustitutas se Nunca exportados o importados, que se nunca se expone fuera de la base de datos de excepto los datos como transitorios (la mayoría , obviamente, en la ejecución de aplicaciones que tienen un "en vivo "conexión a la base de datos ).

Answer 4

"¿Por qué 'los usuarios deben ser capaces de identificar objetos en función de una identificación fácil de usar'?

En mi opinión, los usuarios deben itentify registros utilizando códigos.

Digamos que su base de datos contiene productos (como usted lo mencionó en la Pregunta). ¿No sería mejor si tuvieran códigos para representar productos, que los usuarios pudieran ingresar?

Digamos que tiene mesas y sillas, como usuario, yo preferiría usando tbl y chr que 1 y 2 para identificar de lo que estoy hablando.

Answer 5

Para ser más específico acerca de su pregunta, sí hay otros problemas con el uso de GUID como claves primarias en las bases de datos:

El problema no es tanto con el uso de un GUID como clave primaria, su utilizando un GUID no secuencial como índice agrupado para una tabla.

Lo que aquí se puede extraer es utilizar otros campos como el índice agrupado o usar un GUID secuencial para evitar esta fragmentación.