¿Clave primaria compuesta contra columna adicional "ID"?

Si tuviéramos una table como esta:

Libros (pretender "ISBN" no existe)

  • Autor
  • Título
  • Edición
  • Año de publicacion
  • Precio

Se podría argumentar que {Author, Title, Edition} podría ser una key candidata / primaria.

¿Qué determina si la key candidata / principal debe ser {Autor, Título, Edición} o si se debe usar una columna de ID, con {Autor, Título, Edición} una restricción única de índice / key?

Asi es

  • Autor (PK)
  • Título (PK)
  • Edición (PK)
  • Año de publicacion
  • Precio

mejor, o:

  • ID (PK)
  • Autor
  • Título
  • Edición
  • Año de publicacion
  • Precio

donde {Author, Title, Edition} es un índice / restricción único adicional?

Digamos que {Author,Title,Edition} identifica un libro de manera única, luego se cumple lo siguiente:

  1. Es una (super) key – identifica de forma única una tupla (fila).

  2. Es irnetworkinguctible: eliminar cualquiera de las columnas ya no la convierte en una key.

  3. Es una key candidata: una key irnetworkingucible es una key candidata.

Ahora consideremos el ID (integer)

Puedo razonar que la key de la tabla Book aparecerá en algunas otras tablas como una key externa y también en algunos índices. Por lo tanto, ocupará bastante espacio, digamos tres columnas x 40 caracteres (o lo que sea …) en cada una de estas tablas más en índices coincidentes.

Para hacer que estas "otras" tablas e índices sean más pequeños, puedo agregar una columna de integer único a la tabla Book para usarla como key a la que se hará reference como key externa. Diga algo como:

 alter table `Book` add `BookID` integer not null identity; 

Dado que BookID es (debe ser) único también, la tabla Book ahora tiene dos keys candidatas.

Ahora puedo seleccionar BookID como key principal.

 alter table Book add constraint pk_Book primary key (BookID); 

Sin embargo, el {Author,Title,Edition} debe ser una key (única) para evitar algo como esto:

 BookID Author Title Edition ----------------------------------------------- 1 CJDate Database Design 1 2 CJDate Database Design 1 

Para resumir, agregar el BookID (y elegirlo como el principal) no impidió que {Author,Title,Edition} fuera una key (candidata). Todavía debe tener su propia restricción única y generalmente el índice coincidente.

También tenga en count que desde el punto de layout, esta decisión se realizó en el "nivel físico". En general, en el nivel lógico del layout, este ID no existe: se introdujo durante la consideración de los tamaños e índices de las columnas. Entonces el esquema físico se derivó del lógico. Dependiendo del tamaño de DB, RDBMS y hardware utilizado, ninguno de esos razonamientos de tamaño puede tener un efecto medible, por lo que usar {Author,Title,Edition} como PK puede ser un layout perfectamente bueno, hasta que se demuestre lo contrario.

En general, no desea que la key principal cambie el valor. Esta es la razón por la cual se usan keys primarias ciegas o sustitutas.

Supongamos que creó su tabla Libro con Autor como parte de la key principal.

Suponga que descubrió después de aproximadamente un año que escribió mal "Ray Bradbury". O peor aún, escribiste mal "Rachael Bloom". Solo imagina cuántas filas de bases de datos tendrías que modificar para corregir el error ortográfico. Imagínese cuántas references de índice deben cambiarse.

Sin embargo, si tiene una tabla de Autor con una key sustituta, solo debe corregir una fila. No hay que cambiar los índices.

Finalmente, los nombres de las tablas de la database son usualmente singulares (Libro), en lugar de plural (Libros).

Otra buena razón para usar el escenario de la key primaria sustituta es si la restricción de exclusividad debería cambiar en el futuro (por ejemplo, se debe agregar el ISBN para hacer que un libro sea único). Reorganizar sus datos será mucho más fácil.

Hay muchos artículos relacionados con esto. Los problemas con la key compuesta en su caso:

  1. difícil vincular libros con otras entidades
  2. Es difícil editarlos en una grilla ya que la mayoría de las grillas no admiten keys compuestas (p. Ej., Grilla de kendo, jqgrid)
  3. Puede escribir mal Autor, Título, Edición

También sería bueno normalizar sus datos y almacenar solo una identificación para el autor como (dasblinkenlight) sugirió. En el peor de los casos, cambiará el nombre de él / ella (por ejemplo, se casará y le gusta su nuevo nombre).