sql >> Base de Datos >  >> RDS >> Sqlserver

¿Clave principal compuesta frente a columna de ID adicional?

Di que {Author, Title, Edition} identifica un libro de forma única, entonces se cumple lo siguiente:

  1. Es una superclave:identifica de forma única una tupla (fila).

  2. Es irreducible:eliminar cualquiera de las columnas ya no lo convierte en una clave.

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

Ahora consideremos el ID (entero)

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

Para hacer que estas "otras" tablas e índices sean más pequeños, puedo agregar una columna entera única al Book tabla que se utilizará como clave a la que se hará referencia como clave externa. Di algo como:

alter table Book add BookID integer not null identity;

Con BookID siendo (debe ser) único también, el Book la tabla ahora tiene dos claves candidatas.

Ahora puedo seleccionar el BookID como clave principal.

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

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

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

Para resumir, agregando el BookID -- y elegirlo como principal -- no detuvo {Author, Title, Edition} siendo una clave (candidata). Todavía debe tener su propia restricción única y, por lo general, el índice coincidente.

También tenga en cuenta que desde el punto de diseño, esta decisión se tomó en el "nivel físico". En general, en el nivel lógico de diseño, este ID no existe:se introdujo durante la consideración de los tamaños de columna y los índices. Entonces, el esquema físico se derivó del lógico. Según el tamaño de la base de datos, el RDBMS y el 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.