database - secundarias - ¿Puedo tener varias claves primarias en una sola tabla?

una tabla puede tener dos llaves primarias sql server

Question

¿Puedo tener varias claves primarias en una sola tabla?

Answer 1

(He estado estudiando estos, mucho)

Sólo puede haber 1 clave principal.
Pero puedes tener múltiples claves alternativas.

En simple este es el caso:

• Puede haber varias claves de Candidato (columnas mínimas, para identificar de forma única la fila) en una tabla.
• Una de las claves candidatas se elige específicamente y se denomina clave principal
• Todas las demás claves candidatas se llaman claves alternativas
• Tanto la clave principal como la clave alternativa pueden ser claves compuestas s (2 o más columnas)

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

Answer 2

Algunas personas usan el término "clave principal" para referirse exactamente a una columna entera que obtiene sus valores generados por algún mecanismo automático. Por ejemplo, AUTO_INCREMENT en MySQL o IDENTITY en Microsoft SQL Server. ¿Estás usando 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 puedes hacer esto, obtienes 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 base de datos, puede definir más de una columna de generación automática en una tabla.

Answer 3

Como han señalado los demás, es posible tener claves primarias de varias columnas. Sin embargo, debe tener en cuenta que si tiene algunas dependencias funcionales que no están introducidas por una clave, debe considerar la normalizing 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 un zip_code está asociado a un area y, por lo tanto, existe 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 .

Answer 4

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

¿Cuál sería el punto de tener múltiples columnas de generación automática?

Este código a continuación tiene una clave primaria compuesta. Una de sus columnas es auto-incrementada. Esto funcionará sólo 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 |
+--------+----+---------+

Answer 5

Primary Key es una notación muy desafortunada, debido a la connotación de "Primary" 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 de negocio" que comprenden una clave para la entidad. Boyce, Codd, Date y otros se refieren a estos en el Modelo Relacional como Claves Candidatas. Cuando construimos tablas para estas entidades, sus claves de candidato se convierten en claves naturales en esas tablas. Es solo a través de las Claves naturales que los usuarios pueden identificar de forma única las filas en las tablas; como claves sustitutas siempre deben estar ocultas a los usuarios. Esto se debe a que las Claves Subrogadas no tienen significado comercial.

Sin embargo, el modelo físico para nuestras tablas será, en muchos casos, 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 de claves en el índice agrupado (ignorar las tablas implementadas como montones por un momento). Cuando nuestra (s) Clave (s) Natural (es) disponible (s) esta (1) amplía el ancho de nuestros nodos de hoja no agrupados, aumentando los requisitos de almacenamiento y los accesos de lectura para búsquedas y exploraciones de ese índice no agrupado; y (2) reduce la expansión de nuestro índice agrupado, lo que aumenta la altura y el tamaño del índice, lo que también aumenta 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 caché.

Aquí es donde una clave sustituta pequeña, designada para el RDBMS como "la clave principal" resulta beneficiosa. Cuando se establece como la clave de agrupación en clúster, para ser utilizada para búsquedas de clave en el índice agrupado de índices no agrupados y búsquedas de clave externa de tablas relacionadas, todas estas desventajas desaparecen. Nuestros fan-outs de índices agrupados aumentan nuevamente para reducir la altura y el tamaño de los índices agrupados, 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 agrupamiento. Si se utiliza un GUID como clave de agrupación, la situación será a menudo peor que si se hubiera utilizado la Clave natural más pequeña disponible. Si la tabla está organizada como un montón, entonces se utilizará el RowID de 8 bytes (montón) para las búsquedas de claves, lo que es mejor que un GUID de 16 bytes pero menos eficaz que un entero de 4 bytes.

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

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

Considera 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 apellido largo de Unicode más un entero de 4 bytes, sería deseable (1) aplicar de forma declarativa esta restricción como " ADD CONSTRAINT pk_PersonID UNIQUE NONCLUSTERED (P_Id , Apellido) "y (2) declaran por separado que una clave sustituta pequeña es la" clave principal "de un índice agrupado. Vale la pena señalar que, posiblemente, Anita solo desee agregar el apellido a esta restricción para que sea un campo cubierto, que no es necesario 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. Mi entendimiento es 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.

Answer 6

Sí, es posible en SQL, pero no podemos establecer más de una clave principal 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)
);

Answer 7

Se dieron buenas respuestas técnicas de una manera mejor de lo que puedo hacer. 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. Comprender el núcleo de por qué no es aceptable.
2. Cavar 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 y trata de crear una solución adaptativa.

Espero que ayude a alguien.

Answer 8

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.

Answer 9

Tener dos claves primarias al mismo tiempo, no es posible. Pero (suponiendo que no haya desordenado el caso con una clave compuesta), es posible que lo que necesite 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 ''súper clave'' que tiene una propiedad adicional que al eliminar cualquier atributo de la clave, hace que esa clave no sea más una ''súper clave'' (o simplemente una ''clave'' es una súper clave mínima). Si hay más claves, todas son claves candidatas. Seleccionamos una de las claves candidatas como clave principal. Es por eso que hablar de varias claves primarias para una relación o tabla es ser un conflicto.

Answer 10

Una clave principal es la clave que identifica de forma única 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 usa para unirse a las tablas secundarias, pero esto no es un requisito. El verdadero propósito de un 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 poner varios campos en una clave principal (un PK compuesto). Esto hará que sus uniones sean más lentas (especialmente si son campos de tipo de cadena más grandes) y que sus índices sean 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. caso base Cuando haces esto, cada campo en sí no es único, pero la combinación de ellos es. Si uno o más de los campos en una clave compuesta también deben ser únicos, entonces necesita un índice único en ella. Sin embargo, es probable que si un campo es único, este es un mejor candidato para el PK.

Ahora, a veces, tienes más de un candidato para el PK. En este caso, usted elige una como PK o usa una clave sustituta (yo 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 fueron elegidas como PK. Si los datos deben ser únicos, necesita un índice único, ya sea el PK o no. Este es un problema de integridad de los datos. (Tenga en cuenta que esto también es cierto siempre que use una clave sustituta; las personas se meten en problemas con las claves sustitutas porque se olvidan de crear índices únicos en las claves candidatas).

Ocasionalmente, hay ocasiones en las que desea más de una clave sustituta (que normalmente es la PK si las tiene). En este caso, lo que desea no es más PK, sino más campos con claves generadas automáticamente. La mayoría de los DB no lo permiten, pero hay formas de solucionarlo. Primero, considere si el segundo campo podría calcularse en función de la primera clave generada automáticamente (Campo1 * -1 por ejemplo) o quizás la necesidad de una segunda clave generada automáticamente significa que debe crear una tabla relacionada. Las tablas relacionadas pueden estar en una relación uno a uno. Usted haría cumplir eso agregando el PK de la tabla principal a la tabla secundaria y luego agregando el nuevo campo generado automáticamente a la tabla y luego los campos que sean apropiados para esta tabla. Luego elija una de las dos claves como PK y ponga un índice único en la otra (el campo generado automáticamente no tiene que ser un PK). Y asegúrese de agregar el FK al campo que se encuentra en la tabla principal. En general, si no tiene campos adicionales para la tabla secundaria, debe examinar por qué cree que necesita dos campos generados automáticamente.

Answer 11

Una tabla puede tener múltiples claves candidatas. Cada clave candidata es una columna o conjunto de columnas que son ÚNICAS, se toman juntas y NO son NULAS. Por lo tanto, la especificación de valores para todas las columnas de cualquier clave candidata es suficiente para determinar que hay una fila que cumple los criterios, o ninguna fila en absoluto.

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, para designar una de las claves candidatas como la clave principal. También es una práctica común hacer que cualquier clave externa a la tabla haga referencia a la clave principal, en lugar de cualquier otra clave candidata.

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

Answer 12

Una tabla puede tener una clave principal compuesta, que es una clave principal formada por 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.