database-design - tabla - llave primaria compuesta por 2 campos
Por qué utilizar varias columnas como claves principales(clave primaria compuesta) (8)
Este ejemplo está tomado de w3schools .
CREATE TABLE Persons
(
P_Id int NOT NULL,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Address varchar(255),
City varchar(255),
CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)
)
P_Id entiendo, ambas columnas juntas ( P_Id y P_Id ) representan una clave primaria para la tabla Persons . ¿Es esto correcto?
- ¿Por qué alguien querría usar varias columnas como claves principales en lugar de una sola columna?
- ¿Cuántas columnas se pueden usar juntas como clave principal en una tabla determinada?
El ejemplo de W3Schools no dice cuándo debe usar claves primarias compuestas, y solo está dando sintaxis de ejemplo usando la misma tabla de ejemplo que para otras claves.
Su elección de ejemplo quizás lo engañe al combinar una clave sin sentido (P_Id) y una clave natural (LastName). Esta extraña elección de clave principal dice que las siguientes filas son válidas de acuerdo con el esquema y son necesarias para identificar de forma única a un alumno. Intuitivamente esto no tiene sentido.
1234 Jobs
1234 Gates
Lectura adicional: El gran debate sobre la clave primaria o solo meaningless primary keys Google o incluso leer detenidamente esta pregunta SO
FWIW - Mis 2 centavos es para evitar las claves primarias de múltiples columnas y usar un solo campo de id. Generado (clave sustituta) como clave principal y agregar restricciones adicionales (únicas) donde sea necesario.
Otro ejemplo de claves primarias compuestas es el uso de tablas de asociación. Supongamos que tiene una tabla de personas que contiene un conjunto de personas y una tabla de grupos que contiene un conjunto de grupos. Ahora desea crear una relación de muchos a muchos en persona y grupo. Lo que significa que cada persona puede pertenecer a muchos grupos. Aquí es cómo se vería la estructura de la tabla usando una clave primaria compuesta.
Create Table Person(
PersonID int Not Null,
FirstName varchar(50),
LastName varchar(50),
Constraint PK_Person PRIMARY KEY (PersonID))
Create Table Group (
GroupId int Not Null,
GroupName varchar(50),
Constraint PK_Group PRIMARY KEY (GroupId))
Create Table GroupMember (
GroupId int Not Null,
PersonId int Not Null,
CONSTRAINT FK_GroupMember_Group FOREIGN KEY (GroupId) References Group(GroupId),
CONSTRAINT FK_GroupMember_Person FOREIGN KEY (PersonId) References Person(PersonId),
CONSTRAINT PK_GroupMember PRIMARY KEY (GroupId, PersonID))
Sí, ambos forman la clave principal. Especialmente en tablas donde no tiene una clave sustituta , puede ser necesario especificar múltiples atributos como el identificador único para cada registro (mal ejemplo: una tabla con un nombre y apellido puede requerir que la combinación de ellos sea único).
Su comprensión es correcta.
Lo harías en muchos casos. Un ejemplo es en una relación como OrderHeader y OrderDetail . El PK en OrderHeader podría ser OrderNumber . El PK en OrderDetail podría ser OrderNumber AND LineNumber . Si fuera cualquiera de esos dos, no sería único, pero la combinación de los dos es única.
La alternativa es usar una clave primaria generada (no inteligente), por ejemplo en este caso OrderDetailId . Pero entonces no siempre verías la relación tan fácilmente. Algunas personas prefieren una manera; algunos prefieren el otro camino.
Tu segunda parte pregunta
¿Cuántas columnas se pueden usar juntas como clave principal en una tabla determinada?
es específico de la implementación: está definido en el DBMS real que se está utilizando. [1], [2], [3] Debe inspeccionar las especificaciones técnicas del sistema de base de datos que utiliza. Algunos son muy detallados, otros no. Buscar en la web esta limitación puede ser difícil porque la terminología varía. El término clave primaria compuesta debe ser obligatorio;)
Si no puede encontrar información explícita, intente con una base de datos de prueba para asegurarse de que puede esperar un manejo estable (y específico) de la violación de los límites (que es razonable esperar). Tenga cuidado de obtener la información correcta sobre esto: a veces los límites se acumulan, y verá diferentes resultados con diferentes diseños de base de datos.
Usar una clave principal en varias tablas es útil cuando está usando una tabla intermedia en una base de datos relacional.
Usaré una base de datos que una vez hice para un ejemplo y específicamente tres tablas dentro de esa tabla. Creé una base de datos para un webcomic hace algunos años. Una tabla se llamaba "cómics", una lista de todos los cómics, sus títulos, el nombre del archivo de imagen, etc. La clave principal era "comicnum".
La segunda mesa era "personajes", sus nombres y una breve descripción. La clave principal estaba en "charname".
Como cada cómic, con algunas excepciones, tenía varios personajes y cada personaje aparecía en varios cómics, no era práctico poner una columna en "caracteres" o "cómics" para reflejar eso. En cambio, creo que una tercera mesa se llamaba "comicchars", y esa era una lista de los personajes que aparecían en los cómics. Como esta tabla se unió esencialmente a las dos tablas, solo necesitó dos columnas: charname y comicnum, y la clave principal estaba en ambas.
Utiliza una clave compuesta (una clave con más de un atributo) siempre que quiera garantizar la singularidad de una combinación de varios atributos. Una sola clave de atributo no lograría lo mismo.
Varias columnas en una clave van, en general, a funcionar peor que una clave sustituta. Prefiero tener una clave sustituta y luego un índice único en una clave de varias columnas. De esa manera, puede tener un mejor rendimiento y mantener la singularidad necesaria. Y aún mejor, cuando cambia uno de los valores en esa clave, no es necesario actualizar un millón de entradas secundarias en 215 tablas secundarias.