¿Cuál es la diferencia entre la clave principal y la restricción de clave única?

Question

¿Cuál es la diferencia entre Primary key y unique Key constraint?

¿De qué sirve?

Answer 1

Ambos se utilizan para denotar candidate keys para una tabla.

Solo puede tener una clave principal para una tabla, por lo que solo tendrá que elegir una si tiene varios candidatos.

Cualquiera se puede utilizar en restricciones de clave externa. En SQL Server, las columnas Clave principal no pueden ser anulables. Las columnas utilizadas en las restricciones de clave única pueden ser.

De forma predeterminada en SQL Server, la clave principal se convertirá en el índice agrupado si se crea en un montón, pero de ninguna manera es obligatorio que PK e índice agrupado sean los mismos.

Answer 2

Clave primaria:

1. Clave principal no es más que lo identifica de forma única cada fila de una tabla.

2. La clave principal no permite valores duplicados, ni NULL.

3. La clave principal por defecto es un índice agrupado.

4. Una tabla solo puede tener una clave principal.

Clave única:

1. Clave única es otra cosa que identifica de forma única cada fila de una tabla.

2. La clave única no permite valores duplicados, pero permite (como máximo uno) NULL.

3. La clave única de forma predeterminada es un índice no agrupado.

Este es un enlace completo de la fruta para entender la clave principalDatabase Keys. Tenga en cuenta que sólo tenemos un índice agrupado en una tabla [hablando de SQL Server 2005]. Ahora, si queremos agregar otra columna única, utilizaremos clave única columna, porque columna de clave única se puede agregar más de uno.

Answer 3

Una clave principal es aquella que se utiliza para identificar la fila en cuestión. También podría tener algún significado más allá de eso (si ya existía una porción de datos "reales" que podrían servir) o puede ser puramente un artefacto de implementación (la mayoría de las columnas IDENTITY y valores equivalentes autoincrementados en otros sistemas de bases de datos).

Una clave única es un caso más general, donde una clave no puede tener valores repetidos. En la mayoría de los casos, las personas no pueden tener los mismos números de seguridad social en relación con la misma jurisdicción (un caso internacional podría diferir). Por lo tanto, si almacenamos números de seguridad social, entonces querríamos modelarlos como únicos, ya que cualquier caso de que coincidan con un número existente es claramente incorrecto. Los nombres de usuario generalmente también deben ser únicos, así que aquí hay otro caso. Los identificadores externos (identificadores usados ​​por otro sistema, estándar o protocolo) tienden a ser también únicos, p. solo hay un idioma que tiene un código ISO 639 dado, por lo que si almacenamos códigos ISO 639, lo modelaríamos como único.

Esta singularidad también puede encontrarse en más de una columna. Por ejemplo, en la mayoría de los sistemas de categorización jerárquica (por ejemplo, una estructura de carpetas), ningún elemento puede tener el mismo elemento primario y el mismo nombre, aunque podría haber otros elementos con el mismo padre y diferentes nombres, y otros con el mismo nombre y diferente padres Esta capacidad de múltiples columnas también está presente en las claves principales.

Una tabla también puede tener más de una clave única. P.ej. un usuario puede tener tanto un número de identificación como un nombre de usuario, y ambos deberán ser únicos.

Cualquier clave única que no se pueda nulos puede, por lo tanto, servir como clave principal. A veces, las claves primarias que provienen de los datos innatas que se modelan se conocen como "claves primarias naturales", porque son una parte "natural" de los datos, en lugar de solo un artefacto de implementación. La decisión sobre cuál utilizar depende de algunas cosas:

1. probabilidad de un cambio de especificación. Si modelamos un número de seguro social como único y luego tuvimos que adaptarnos para permitir múltiples jurisdicciones donde dos o más usan un sistema de numeración lo suficientemente similar para permitir colisiones, es probable que necesitemos eliminar la restricción de exclusividad (se necesitan otros cambios puede) Si fuera nuestra clave principal, ahora también necesitamos usar una nueva clave principal, y cambiar cualquier tabla que estuviera usando esa clave principal como parte de una relación, y cualquier consulta que se haya unido a ella.

2. Velocidad de búsqueda. La eficiencia clave puede ser importante, ya que se usan en muchas cláusulas WHERE y (más a menudo) en muchas JOIN s. Con JOINS en particular, la velocidad de búsqueda puede ser vital. El impacto dependerá de los detalles de la implementación, y las diferentes bases de datos varían de acuerdo con cómo manejarán diferentes tipos de datos (me gustaría tener pocos reparos desde el punto de vista del rendimiento al usar una gran parte de texto como clave principal en Postgres donde podría especificar el uso de hash se une, pero dudaría mucho en hacerlo en SQLServer [Editar: para "grande", estoy pensando en el tamaño de un nombre de usuario, ¡no en el tamaño de todo el Edda Norse!]).

3. La frecuencia de la clave es la única información interesante. Por ejemplo, con una tabla de idiomas y una tabla de comentarios en ese idioma, muy a menudo la única razón por la que quisiera unirme a la tabla de idiomas al tratar con la tabla de comentarios es obtener el código de idioma o restringir una consulta a aquellos con un código de idioma particular. Es probable que se use mucho menos información sobre el idioma. En este caso, al unirse en el código es menos eficiente que unirse en un conjunto de identificación numérica desde una columna IDENTITY, teniendo el código como la clave primaria y, por lo tanto, como lo que está almacenado en la columna de clave externa en la tabla de comentarios. eliminará la necesidad de cualquier JOIN en absoluto, con una ganancia de eficiencia considerable. Sin embargo, con mayor frecuencia quiero más información de las tablas relevantes que eso, por lo que hacer que JOIN sea más eficiente es más importante.

Answer 4

versión corta:

• Desde el punto de vista de la teoría de base de datos, no hay ninguno. Ambas son simplemente claves candidatas.
• En la práctica, a la mayoría de DMBS le gusta tener una "clave estándar", que se puede usar para, p. Ej. decidir cómo almacenar datos, y decirle a las herramientas y clientes de DB cuál es la mejor manera de identificar un registro.

Por lo tanto, distinguir una clave única como la "clave principal" es solo una conveniencia de implementación (pero una importante).

Answer 5

Una clave principal es cualquier clave candidata. En principio, las claves primarias no son diferentes de cualquier otra clave candidata porque todas las claves son iguales en el modelo relacional.

SQL, sin embargo, tiene dos sintaxis diferentes para implementar claves candidatas: la restricción PRIMARY KEY y la restricción UNIQUE (en columnas que no admiten nulos, por supuesto). En la práctica, logran exactamente lo mismo excepto por la restricción esencialmente inútil de que una PRIMARY KEY solo puede usarse una vez por tabla, mientras que una restricción UNIQUE se puede usar varias veces.

Así que no hay un "uso" fundamental para la restricción PRIMARY KEY. Es redundante y podría ser fácilmente ignorado o eliminado del lenguaje por completo. Sin embargo, a muchas personas les resulta conveniente señalar que una clave en particular por mesa tiene un significado especial. Existe una convención ampliamente observada de que las claves designadas con PRIMARY KEY se utilizan para referencias de clave externa, aunque esto es totalmente opcional.

Answer 6

Tanto la clave principal como la clave única se utilizan para imponer la exclusividad de una columna. Entonces, ¿cuándo eliges uno sobre el otro?

Una tabla puede tener, solo una clave principal. Si desea imponer la exclusividad en 2 o más columnas, entonces usamos una restricción de clave única.

Diferencia entre la restricción de clave primaria y la restricción de clave única?

1. Una tabla sólo puede tener una clave principal, pero más de una clave

2. clave primaria única no permite valores nulos, donde key como único permite una nula

ALTER TABLE Table_Name 
ADD CONSTRAINT Constraint_Name PRIMARY KEY (Column_Name) 

Alter Table Table_Name 
Add Constraint Constraint_Name Unique(Column_Name)