Por qué utilizar varias columnas como claves primarias (clave primaria compuesta)

109

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)
)

Tengo entendido que ambas columnas juntas ( P_Idy LastName) representan una clave principal 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?
database-design relational-database primary-key ddl database-table rockbala
fuente
... ahora también hay una respuesta para la segunda pregunta
Wolf
1
@Martijn Peters. ¿Por qué se eliminó la respuesta?
PerformanceDBA

Respuestas:

119

Su comprensión es correcta.

Haría esto en muchos casos. Un ejemplo está en una relación como OrderHeadery OrderDetail. El PK en OrderHeaderpodría ser OrderNumber. El PK en OrderDetailpodría ser OrderNumberAND LineNumber. Si fuera cualquiera de esos dos, no sería único, pero la combinación de los dos está garantizada como única.

La alternativa es utilizar 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 forma; algunos prefieren lo contrario.

MJB
fuente
2
¿Es esto útil si estoy usando branch_id y usando la replicación entre dos bases de datos, resolverá el duplicado de identificadores?
Mhmd
11
Tenga en cuenta que en muchos casos de uso de una clave primaria generada, a menudo aún desea una clave única en los valores compuestos.
Bocaditos de tocino
Explique en detalle "Algunas personas prefieren una forma, otras prefieren la otra".
Nombre de usuario
1
¿Por favor, elaborado? No está seguro de qué decir. He conocido personas que prefieren tener múltiples campos concatenados como clave porque es más fácil de entender intuitivamente lo que están viendo. He conocido a otros que prefieren simplemente asignar una clave única a cada fila porque es más fácil y rápido de escribir. ¿Eso es lo que está preguntando?
MJB
Ese mensaje estaba destinado a @Username. Olvidé dirigirlo.
MJB
26

Otro ejemplo de claves primarias compuestas es el uso de tablas de asociación. Suponga 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 en grupo. Lo que significa que cada persona puede pertenecer a muchos grupos. Así es como 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))
John Hartsock
fuente
gran explicación: creo que la necesidad de atributos para las relaciones m-a-n (en una fase normalizada) es la clave.
Wolf
tal vez agregar un pequeño beneficio explicación sería aún mejor
Martian2049
10

El ejemplo de W3Schools no dice cuándo debe usar claves primarias compuestas, y solo proporciona una sintaxis de ejemplo utilizando la misma tabla de ejemplo que para otras claves.

Su elección de ejemplo quizás lo esté engañando al combinar una clave sin sentido (P_Id) y una clave natural (LastName). Esta extraña elección de clave primaria dice que las siguientes filas son válidas de acuerdo con el esquema y son necesarias para identificar de forma única a un estudiante. Intuitivamente, esto no tiene sentido.

1234     Jobs
1234     Gates

Lectura adicional: El gran debate de la clave primaria o simplemente Google meaningless primary keyso incluso lea detenidamente esta pregunta SO

FWIW - Mi 2 centavos es evitar claves primarias de varias columnas y usar un solo campo de identificación generado (clave sustituta) como clave primaria y agregar restricciones adicionales (únicas) cuando sea necesario.

Robert Paulson
fuente
1
1) el enlace del "gran debate de la clave primaria" es particularmente estúpido, la información es falsa y egoísta. 2) No se puede evitar el índice de las columnas que hacen que la fila sea única. Un ID "sustituto" con un índice es siempre una columna adicional y un índice adicional. Bastante tonto porque es redundante. Y más lento.
PerformanceDBA
2
El "gran debate de la clave primaria" no es estúpido. Es un problema muy válido para los desarrolladores que no son desarrolladores de sql ni DBA de sql y no pasan todo su tiempo en sql. Incluso en sql puro, preferiría tener una clave generada automáticamente sin sentido como clave principal al unirme a tener que recordar pasar n bits de datos como clave natural. Eres bienvenido a tu punto de vista, pero agradeceríamos no ser tan despectivo.
Robert Paulson
4

Utilice una clave compuesta (una clave con más de un atributo) siempre que desee garantizar la unicidad de una combinación de varios atributos. Una sola clave de atributo no lograría lo mismo.

nvogel
fuente
1
En cuanto a garantizar una clave única, puede confiar en la combinación de dos atributos para formar una clave que lógicamente no se puede duplicar. La persona y la fecha de graduación de un conjunto de datos más grande serían un ejemplo.
John Mark
3

Sí, ambos forman la clave principal. Especialmente en las tablas en las que no tiene una clave sustituta , puede ser necesario especificar varios atributos como identificador único para cada registro (mal ejemplo: una tabla con un nombre y un apellido puede requerir que se combinen único).

ig0774
fuente
3

Varias columnas en una clave, en general, tendrán un rendimiento 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 se mantiene la singularidad necesaria. Y lo que es aún mejor, cuando uno de los valores de esa clave cambia, tampoco es necesario actualizar un millón de entradas secundarias en 215 tablas secundarias.

HLGEM
fuente
1
1) Rendimiento. No en una plataforma SQL (tal vez en los "sql" simulados y el software gratuito). 2) La preferencia es irrelevante. Lo que requieren las tablas, para la integridad, es relevante. 3) Un ID "sustituto" con un índice es siempre una columna adicional y un índice adicional . Entonces eso sería más lento, en cualquier plataforma. Re performance, te contradices. 4) Si no sabe cómo actualizar correctamente el mítico "millón de entradas secundarias en 215 tablas secundarias" , haga una pregunta.
PerformanceDBA
2
No estoy de acuerdo con la afirmación 'Varias columnas en una clave, en general, funcionarán peor que una clave sustituta'. A menudo, se requiere una consulta adicional para obtener la clave sustituta de una relación cuando la considera. En ese punto, es un viaje de ida y vuelta adicional más lento en cuanto a rendimiento.
ttugates
3

Tu segunda pregunta

¿Cuántas columnas se pueden usar juntas como clave principal en una tabla determinada?

es específico de la implementación: se define 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 acerca de tales limitaciones puede resultar difícil porque la terminología varía. El término clave primaria compuesta debería ser obligatorio;)

Si no puede encontrar información explícita, intente crear una base de datos de prueba para asegurarse de que puede esperar un manejo estable (y específico) de las violaciones de los límites (que son de 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.

Lobo
fuente
2

El uso de una clave principal en varias tablas resulta útil cuando se utiliza una tabla intermedia en una base de datos relacional.

Usaré una base de datos que hice una vez como 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 tabla era "personajes", sus nombres y una breve descripción. La clave principal estaba en "charname".

Dado que 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 "personajes" o "cómics" para reflejar eso. En cambio, creé una tercera tabla llamada "comicchars", y esa era una lista de qué personajes aparecían en qué cómics. Dado que esta tabla esencialmente unió las dos tablas, solo necesitaba dos columnas: charname y comicnum, y la clave principal estaba en ambas.

Sr. Hombre Inicial
fuente
1

Creamos claves primarias compuestas para garantizar los valores de columna de unicidad que componen un solo registro. Es una restricción que ayuda a evitar la inserción de datos que no deben duplicarse.

es decir, si todas las identificaciones de los estudiantes y los números de certificado de nacimiento se asignan de forma única a una sola persona. Entonces sería una buena idea hacer que la clave principal de una persona sea una composición de identificación de estudiante y número de certificado de nacimiento porque evitaría que inserte accidentalmente dos personas que tienen diferentes identificaciones de estudiante y el mismo certificado de nacimiento.

kiwicomb123
fuente