¿Puedo tener varias claves principales en una sola tabla?

¿Puedo tener varias claves principales en una sola tabla?

Una tabla puede tener una clave primaria compuesta, que es una clave primaria hecha de dos o más columnas. Por ejemplo:

CREATE TABLE userdata (
  userid INT,
  userdataid INT,
  info char(200),
  primary key (userid, userdataid)
);

Actualización: Aquí hay un enlace con una descripción más detallada de las claves primarias compuestas.

Solo puede tener una clave principal, pero puede tener varias columnas en su clave principal.

También puede tener índices únicos en su tabla, que funcionarán un poco como una clave principal, ya que impondrán valores únicos y acelerarán la consulta de esos valores.

Una tabla puede tener múltiples claves candidatas. Cada clave candidata es una columna o conjunto de columnas que son ÚNICAS, tomadas juntas, y también NO NULAS. Por lo tanto, especificar valores para todas las columnas de cualquier clave candidata es suficiente para determinar que hay una fila que cumple con los criterios, o ninguna fila.

Las claves candidatas son un concepto fundamental en el modelo de datos relacionales.

Es una práctica común, si hay varias claves presentes en una tabla, designar una de las claves candidatas como clave principal. También es una práctica común hacer que las claves externas de la tabla hagan referencia a la clave primaria, en lugar de cualquier otra clave candidata.

Recomiendo estas prácticas, pero no hay nada en el modelo relacional que requiera seleccionar una clave primaria entre las claves candidatas.

Esta es la respuesta tanto para la pregunta principal como para la pregunta de @ Kalmi de

¿Cuál sería el punto de tener múltiples columnas autogeneradoras?

Este código a continuación tiene una clave primaria compuesta. Una de sus columnas se incrementa automáticamente. Esto solo funcionará en MyISAM. InnoDB generará un error " ERROR 1075 (42000): Definición de tabla incorrecta; solo puede haber una columna automática y debe definirse como una clave ".

DROP TABLE IF EXISTS `test`.`animals`;
CREATE TABLE  `test`.`animals` (
  `grp` char(30) NOT NULL,
  `id` mediumint(9) NOT NULL AUTO_INCREMENT,
  `name` char(30) NOT NULL,
  PRIMARY KEY (`grp`,`id`)
) ENGINE=MyISAM;

INSERT INTO animals (grp,name) VALUES
    ('mammal','dog'),('mammal','cat'),
    ('bird','penguin'),('fish','lax'),('mammal','whale'),
    ('bird','ostrich');

SELECT * FROM animals ORDER BY grp,id;

Which returns:

+--------+----+---------+
| grp    | id | name    |
+--------+----+---------+
| fish   |  1 | lax     |
| mammal |  1 | dog     |
| mammal |  2 | cat     |
| mammal |  3 | whale   |
| bird   |  1 | penguin |
| bird   |  2 | ostrich |
+--------+----+---------+

(He estado estudiando esto, mucho)

Claves candidatas : se requiere una combinación de columnas mínima para identificar de forma exclusiva una fila de la tabla.
Teclas compuestas : 2 o más columnas.

• Pueden existir múltiples claves de candidato en una tabla.
  • CLAVE primaria : solo una de las claves candidatas elegida por nosotros
  • Claves alternativas : todas las demás claves candidatas
    • Tanto la clave primaria como las claves alternativas pueden ser claves compuestas

Fuentes:
https://en.wikipedia.org/wiki/Superkey
https://en.wikipedia.org/wiki/Candidate_key
https://en.wikipedia.org/wiki/Primary_key
https://en.wikipedia.org / wiki / Compound_key

Como señalaron los demás, es posible tener claves primarias de varias columnas. Sin embargo, debe tenerse en cuenta que si tiene algunas dependencias funcionales que no son introducidas por una clave, debería considerar normalizar su relación.

Ejemplo:

Person(id, name, email, street, zip_code, area)

Puede haber una dependencia funcional entre id -> name,email, street, zip_code and area Pero a menudo zip_codese asocia a a areay por lo tanto hay una dependencia funcional interna entre zip_code -> area.

Por lo tanto, uno puede considerar dividirlo en otra tabla:

Person(id, name, email, street, zip_code)
Area(zip_code, name)

Para que sea consistente con la tercera forma normal .

La clave primaria es una notación muy desafortunada, debido a la connotación de "primaria" y la asociación subconsciente en consecuencia con el modelo lógico. Así evito usarlo. En su lugar, me refiero a la clave sustituta del modelo físico y las claves naturales del modelo lógico.

Es importante que el Modelo Lógico para cada Entidad tenga al menos un conjunto de "atributos comerciales" que comprendan una Clave para la entidad. Boyce, Codd, Date et al se refieren a estos en el Modelo Relacional como Candidate Keys. Cuando creamos tablas para estas Entidades, sus Claves candidatas se convierten en Claves naturales en esas tablas. Es solo a través de esas Claves naturales que los usuarios pueden identificar de forma exclusiva las filas en las tablas; como claves sustitutas siempre deben ocultarse a los usuarios. Esto se debe a que las claves sustitutas no tienen sentido comercial.

Sin embargo, el modelo físico para nuestras tablas en muchos casos será ineficiente sin una clave sustituta. Recuerde que las columnas no cubiertas para un índice no agrupado solo se pueden encontrar (en general) a través de una búsqueda clave en el índice agrupado (ignore las tablas implementadas como montones por un momento). Cuando nuestras Claves naturales disponibles son anchas, esto (1) amplía el ancho de nuestros nodos hoja no agrupados, lo que aumenta los requisitos de almacenamiento y los accesos de lectura para búsquedas y escaneos de ese índice no agrupado; y (2) reduce el despliegue de nuestro índice agrupado aumentando la altura del índice y el tamaño del índice, nuevamente aumentando las lecturas y los requisitos de almacenamiento para nuestros índices agrupados; y (3) aumenta los requisitos de caché para nuestros índices agrupados. persiguiendo otros índices y datos fuera de la memoria caché.

Aquí es donde una pequeña clave sustituta, designada para el RDBMS como "la clave primaria" resulta beneficiosa. Cuando se establece como la clave de agrupación, para usarse para búsquedas de clave en el índice agrupado de índices no agrupados y búsquedas de clave externa de tablas relacionadas, desaparecen todas estas desventajas. Nuestros despliegues de índice agrupado aumentan nuevamente para reducir la altura y el tamaño del índice agrupado, reducir la carga de caché para nuestros índices agrupados, disminuir las lecturas al acceder a los datos a través de cualquier mecanismo (ya sea exploración de índice, búsqueda de índice, búsqueda de clave no agrupada o búsqueda de clave externa) y disminuir los requisitos de almacenamiento para los índices agrupados y no agrupados de nuestras tablas.

Tenga en cuenta que estos beneficios solo se producen cuando la clave sustituta es pequeña y la clave de agrupación. Si se utiliza un GUID como clave de agrupamiento, la situación a menudo será peor que si se hubiera utilizado la Clave natural más pequeña disponible. Si la tabla está organizada como un montón, entonces el RowID de 8 bytes (montón) se usará para búsquedas de claves, que es mejor que un GUID de 16 bytes pero menos eficaz que un entero de 4 bytes.

Si se debe utilizar un GUID debido a restricciones comerciales, vale la pena buscar una clave de agrupación mejor. Si, por ejemplo, es posible un pequeño identificador de sitio y un "número de secuencia de sitio" de 4 bytes, entonces ese diseño podría proporcionar un mejor rendimiento que un GUID como clave sustituta.

Si las consecuencias de un montón (quizás una combinación hash) hacen que el almacenamiento preferido sea entonces los costos de una clave de agrupamiento más amplia deben equilibrarse en el análisis de compensación.

Considere este ejemplo ::

ALTER TABLE Persons
ADD CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)

donde la tupla " (P_Id, LastName) " requiere una restricción de unicidad, y puede ser un largo Unicode LastName más un entero de 4 bytes, sería deseable (1) aplicar declarativamente esta restricción como " ADD CONSTRAINT pk_PersonID UNIQUE NONCLUStered (P_Id , Apellido) "y (2) declaran por separado que una pequeña clave sustituta es la" clave principal "de un índice agrupado. Vale la pena señalar que Anita posiblemente solo desea agregar el Apellido a esta restricción para que sea un campo cubierto, lo cual es innecesario en un índice agrupado porque TODOS los campos están cubiertos por él.

La capacidad en SQL Server para designar una clave primaria como no agrupada es una circunstancia histórica desafortunada, debido a una combinación del significado "clave natural o candidata preferida" (del Modelo lógico) con el significado "clave de búsqueda en almacenamiento" del Físico Modelo. Tengo entendido que originalmente SYBASE SQL Server siempre usaba un RowID de 4 bytes, ya sea en un montón o en un índice agrupado, como la "clave de búsqueda en el almacenamiento" del Modelo físico.

Algunas personas usan el término "clave primaria" para referirse exactamente a una columna entera que obtiene sus valores generados por algún mecanismo automático. Por ejemplo AUTO_INCREMENTen MySQL o IDENTITYen Microsoft SQL Server. ¿Estás usando la clave primaria en este sentido?

Si es así, la respuesta depende de la marca de la base de datos que esté utilizando. En MySQL, no puede hacer esto, obtiene un error:

mysql> create table foo (
  id int primary key auto_increment, 
  id2 int auto_increment
);
ERROR 1075 (42000): Incorrect table definition; 
there can be only one auto column and it must be defined as a key

En algunas otras marcas de bases de datos, puede definir más de una columna de generación automática en una tabla.

Tener dos claves principales al mismo tiempo no es posible. Pero (suponiendo que no haya desordenado el caso con la clave compuesta), lo que podría necesitar es hacer que un atributo sea único.

CREATE t1(
c1 int NOT NULL,
c2 int NOT NULL UNIQUE,
...,
PRIMARY KEY (c1)
);

Sin embargo, tenga en cuenta que en la base de datos relacional, una 'súper clave' es un subconjunto de atributos que identifican de forma única una tupla o fila en una tabla. Una 'clave' es una 'superclave' que tiene una propiedad adicional que al eliminar cualquier atributo de la clave, hace que esa clave ya no sea una 'superclave' (o simplemente una 'clave' es una superclave mínima). Si hay más claves, todas ellas son claves candidatas. Seleccionamos una de las claves candidatas como clave principal. Es por eso que hablar de varias claves principales para una relación o tabla es un conflicto.

Una clave primaria es la clave que identifica de forma exclusiva un registro y se utiliza en todos los índices. Por eso no puedes tener más de uno. También es generalmente la clave que se utiliza para unirse a tablas secundarias, pero esto no es un requisito. El verdadero propósito de una PK es asegurarse de que algo le permita identificar un registro de manera única para que los cambios en los datos afecten al registro correcto y para que se puedan crear índices.

Sin embargo, puede colocar varios campos en una clave primaria (una PK compuesta). Esto hará que sus uniones sean más lentas (especialmente si son campos de tipo cadena más grandes) y sus índices más grandes, pero puede eliminar la necesidad de hacer uniones en algunas de las tablas secundarias, en lo que respecta al rendimiento y el diseño, tómelo en un caso por base de caso Cuando hace esto, cada campo en sí no es único, pero la combinación de ellos sí lo es. Si uno o más de los campos en una clave compuesta también deben ser únicos, entonces necesita un índice único en él. Sin embargo, es probable que si un campo es único, este sea un mejor candidato para el PK.

Ahora, a veces, tienes más de un candidato para el PK. En este caso, elige una como PK o utiliza una clave sustituta (personalmente prefiero las claves sustitutas para esta instancia). Y (¡esto es crítico!) Agrega índices únicos a cada una de las claves candidatas que no se eligieron como PK. Si los datos deben ser únicos, necesita un índice único, ya sea PK o no. Este es un problema de integridad de datos. (Tenga en cuenta que esto también es cierto cada vez que usa una clave sustituta; las personas se meten en problemas con las claves sustitutas porque se olvidan de crear índices únicos en las claves candidatas).

En ocasiones, hay ocasiones en las que desea más de una clave sustituta (que generalmente son PK si las tiene). En este caso, lo que desea no son más PK, son más campos con claves autogeneradas. La mayoría de los DB no permiten esto, pero hay formas de evitarlo. Primero considere si el segundo campo podría calcularse en función de la primera clave autogenerada (Campo1 * -1, por ejemplo) o tal vez la necesidad de una segunda clave autogenerada realmente significa que debe crear una tabla relacionada. Las tablas relacionadas pueden estar en una relación uno a uno. Para hacer cumplir eso, agregue el PK de la tabla primaria a la tabla secundaria y luego agregue el nuevo campo autogenerado a la tabla y luego los campos que sean apropiados para esta tabla. Luego, elija una de las dos claves como PK y coloque un índice único en la otra (el campo autogenerado no tiene que ser un PK). Y asegúrese de agregar el FK al campo que está en la tabla principal. En general, si no tiene campos adicionales para la tabla secundaria, debe examinar por qué cree que necesita dos campos autogenerados.

Se dieron buenas respuestas técnicas de una mejor manera que yo. Solo puedo agregar a este tema:

Si desea algo que no está permitido / aceptable, es una buena razón para dar un paso atrás.

1. Comprenda el núcleo de por qué no es aceptable.
2. Excava más en documentación / artículos de revistas / web y etc.
3. Analizar / revisar el diseño actual y señalar fallas importantes.
4. Considere y pruebe cada paso durante el nuevo diseño.
5. Siempre mira hacia adelante e intenta crear una solución adaptativa.

Espero que ayude a alguien.

Sí, es posible en SQL, pero no podemos configurar más de una clave primaria en MsAccess. Entonces, no sé sobre las otras bases de datos.

CREATE TABLE CHAPTER (
    BOOK_ISBN VARCHAR(50) NOT NULL,
    IDX INT NOT NULL,
    TITLE VARCHAR(100) NOT NULL,
    NUM_OF_PAGES INT,
    PRIMARY KEY (BOOK_ISBN, IDX)
);