recomendaciones - porque se dañan las tablas en mysql

¿Clave primaria compuesta frente a columna adicional "ID"?

Question

Si tuviéramos una mesa 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 clave candidata / primaria.

¿Qué determina si la clave candidata / principal debe ser {Author, Title, Edition} o si se debe usar una columna de identificación, con {Author, Title, Edition} una restricción única de índice / clave?

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?

Answer 1

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

Supongamos que creó su tabla Libro con Autor como parte de la clave 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 referencias de índice deben cambiarse.

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

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

Answer 2

Hay muchos artículos relacionados con esto. Los problemas con la clave 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 claves 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).

Answer 3

Otra buena razón para usar el escenario de la clave 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.

Answer 4

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

1. Es una (super) clave - identifica de forma única una tupla (fila).

2. Es irreductible: eliminar cualquiera de las columnas ya no la convierte en una clave.

3. Es una clave candidata: una clave irreducible es una clave candidata.

Ahora consideremos el ID (entero)

Puedo razonar que la clave de la tabla Book aparecerá en algunas otras tablas como una clave 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 entero único a la tabla Book para usarla como clave a la que se hará referencia como clave 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 claves candidatas.

Ahora puedo seleccionar BookID como clave principal.

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

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

BookID  Author      Title           Edition
----------------------------------------------- 
  1      C.J.Date  Database Design     1
  2      C.J.Date  Database Design     1

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

También tenga en cuenta que desde el punto de diseño, esta decisión se realizó en el "nivel físico". En general, en el nivel lógico del diseño, 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 diseño perfectamente bueno, hasta que se demuestre lo contrario.