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

¿Cuál es el uso??

  • Está usted preguntando acerca de la diferencia entre la clave y la restricción (PK y la única restricción) o acerca de PK restricción y el reino unido de restricción?
InformationsquelleAutor pvaju896 | 2010-09-29

5 Comentarios

  1. 12

    Ambos se utilizan para denotar candidato claves para una tabla.

    Sólo puede tener una clave principal de una tabla tan sólo tiene que elegir uno si tiene varios candidatos.

    Pueden ser utilizados en las restricciones de Clave externa. En SQL Server las columnas de Clave Principal no puede ser que aceptan valores null. Las columnas utilizadas en la Única de las restricciones de Clave puede ser.

    Por defecto en SQL Server la Clave Principal será el índice agrupado, si es creado en un montón, pero no es obligatorio que el PK y el índice agrupado debe ser el mismo.

    • ¿Qué quieres decir con «Por defecto en SQL Server la Clave Principal será el índice agrupado, si es creado en un montón»?
    • Un heap es una tabla sin un índice agrupado. Si ejecuta ALTER TABLE dbo.tbl ADD CONSTRAINT PKNAME PRIMARY KEY (foo) en un montón de que va a crear un índice agrupado con las teclas del índice de la PK columnas. Si la tabla ya tiene un índice agrupado se creará un único índice no agrupado.
    • Ah, hubiera sido más comprensible para decir, que el índice clúster puede ser sólo uno en la mesa y si no hay un índice agrupado sin embargo, cuando PK estaba siendo creado, entonces PK es creado clúster (haciendo que la tabla agrupado, no colmadas), de lo contrario PK es CREADO no agrupado. Su frase en respuesta fue ambigua, porque el índice, agrupados o no agrupados, son siempre (crea) en el árbol B, se trata de la tabla de datos puede estar en el montón si estos datos no agrupados. No he entendido mal?
  2. 7

    Una clave primaria es la que se utiliza para identificar la fila en cuestión. También podría tener algún sentido más allá de eso (si ya hubo un pedazo de «real» de datos que podrían servir) o puede ser puramente una implementación artefacto (la mayoría de los IDENTITY columnas, y el equivalente de incremento automático de los valores en otros sistemas de base de datos).

    Una clave única es un caso más general, donde la clave no puede tener valores repetidos. En la mayoría de los casos las personas no pueden tener el mismo número de la seguridad social en relación a la misma jurisdicción (un asunto internacional podrían diferir). Por lo tanto, si estábamos almacenamiento de números de la seguridad social, entonces querríamos modelo como único, como en cualquier caso de coincidencia de un número es claramente errónea. Los nombres de usuario debe ser único también, así que aquí hay otro caso. Externo identificadores (identificadores utilizados por otro sistema, norma o protocolo) también tienden a ser único, por ejemplo, sólo hay un idioma que tiene un determinado código ISO 639, de modo que si vamos a almacenar códigos ISO 639 nos gustaría modelo que como único.

    Esta singularidad puede ser también a través de más de una columna. Por ejemplo, en la mayoría de categorización jerárquica de los sistemas (por ejemplo, una estructura de carpetas) no hay ningún elemento puede tener el mismo elemento padre y con el mismo nombre, aunque podría haber otros elementos con el mismo padre y nombres diferentes, y los demás con el mismo nombre y diferentes a los padres. Este multi-columna de capacidad también está presente en las claves primarias.

    Una tabla también puede tener más de una clave única. E. g. un usuario puede tener un número de id y un nombre de usuario, y ambos deben ser únicas.

    Cualquiera que no aceptan valores null clave única por lo tanto puede servir como una clave principal. A veces las claves principales que provienen de la innata de datos que han sido modelados se conoce como «natural claves primarias», debido a que son «naturales» de la parte de los datos, en lugar de sólo una aplicación artefacto. La decisión de cuál utilizar depende de varios factores:

    1. Probabilidad de cambio de especificación. Si se modela un número de seguro social como único y, a continuación, tuvo que adaptarse para permitir que múltiples jurisdicciones donde dos o más se utilice un similar sistema de numeración para permitir colisiones, es probable que sólo necesita quitar la restricción de unicidad (otros cambios puede ser necesario). Si era nuestra clave primaria, que ahora también debe usar una nueva clave principal, y cambiar cualquier mesa en la que estaba usando esa clave principal como parte de una relación, y cualquier consulta que se unió en él.

    2. Velocidad de look-up. La clave de la eficiencia, puede ser importante, ya que se utilizan en muchos WHERE cláusulas y, con más frecuencia en muchos JOINs. Con JOINS en particular, la velocidad de búsqueda puede ser vital. El impacto dependerá de los detalles de implementación, y diferentes bases de datos varían de acuerdo a cómo se manejan diferentes tipos de datos (me gustaría tener pocos escrúpulos desde una perspectiva de rendimiento en el uso de un gran trozo de texto como clave principal en Postgres donde me podría especificar el uso de combinaciones hash, pero me gustaría ser muy reticentes a hacerlo en sql server [Editar: para los «grandes» estoy pensando en tal vez del tamaño de un nombre de usuario, no algo que el tamaño de todo el Nórdico Eddas!]).

    3. Frecuencia de la llave, la única información interesante. Por ejemplo, con una tabla de idiomas, y una tabla de piezas de los comentarios en la lengua, muy a menudo la única razón por la que se quieren sumar a la tabla de idioma cuando se trata con los comentarios de la tabla es obtener el código de idioma o restringir una consulta para aquellos con un determinado código de idioma. Otra información sobre el idioma es probable que sea mucho más rara vez se utiliza. En este caso, además de participar en el código es probable que sea menos eficiente que la de unirse en un identificador numérico establece a partir de un IDENTITY de la columna, tener el código como la clave principal y, por tanto, como lo que está almacenado en la columna de clave foránea en los comentarios de tabla eliminará la necesidad de UNIR todos, con un considerable aumento de la eficiencia. Más a menudo, aunque quiero más información de las tablas pertinentes, de forma que la combinación más eficaz es más importante.

  3. 5

    Clave principal:

    1. Clave principal no es nada, pero que identifica de forma única a cada fila de una tabla.

    2. Clave principal no permite valores duplicados, ni NULL.

    3. Clave principal por defecto es un índice agrupado.

    4. Una tabla sólo puede tener una clave primaria.

    Clave Única:

    1. Clave única no es nada, pero que identifica de forma única a cada fila de una tabla.

    2. Clave única no permite valores duplicados, pero permite (al menos uno) NULL.

    3. Única clave por defecto es un índice no agrupado.

    Esta es una de las frutas enlace completo para entender la Clave Principal Base De Datos De Claves.
    Tenga en mente que sólo tienen un índice agrupado en una tabla [Hablando acerca de SQL Server 2005].
    Ahora bien, si queremos añadir otra columna única, a continuación, vamos a utilizar Clave Única columna, porque
    Clave única columna se puede agregar más de uno.

    • ¿Qué quieres decir con «no es nada»?
  4. 3

    Una clave primaria es sólo alguna clave candidata. En principio, las claves primarias no son diferentes de cualquier otro candidato clave porque todas las claves son iguales en el modelo relacional.

    SQL, sin embargo, tiene dos sintaxis diferente para la aplicación de candidato claves: la restricción de CLAVE PRINCIPAL y la ÚNICA restricción (en la que no aceptan valores null columnas de curso). En la práctica, lograr exactamente la misma cosa, excepto por el esencialmente inútil restricción de que una CLAVE PRINCIPAL sólo puede ser utilizado una vez por tabla, mientras que una restricción ÚNICA puede ser utilizado varias veces.

    Así que no hay ningún fundamentales «uso» para la restricción de CLAVE PRINCIPAL. Es redundante y puede ser fácilmente ignorado o se quita de la lengua por completo. Sin embargo, muchas personas encuentran que es conveniente descartar una clave determinada por la tabla como de especial importancia. Hay una muy ampliamente observado convención de que las llaves designado con la CLAVE PRINCIPAL se utiliza para extranjeros referencias clave, aunque esto es totalmente opcional.

  5. 1

    Versión corta:

    • Desde el punto de vista de la teoría de la base de datos, no hay ninguno. Ambos son simplemente candidato claves.
    • En la práctica, la mayoría de los DMBS como para tener una «clave», que puede ser utilizado para, por ejemplo, decidir cómo se almacenan los datos, y a decir de herramientas y base de datos de los clientes, que es la mejor manera de identificar un registro.

    Para distinguir una clave única como la «clave principal» es sólo una aplicación de conveniencia (pero muy importante).

    • No es cierto, en términos de la teoría de la base de datos, una clave única puede tener más de un valor null. En SQLServer específicamente esto no está permitido (considerado un defecto por muchos), pero eso es SQLServer específico, no es un db-teoría de la cosa. Debido a esto, una clave única no es suficiente para identificar una fila única, tan lejos como db teoría.
    • Hanna: En la base de la teoría de la clave candidata no puede contener valores null. El término «clave única» es una tautología y/o un nombre inapropiado. Todas las claves son únicas y las teclas están también los que no aceptan valores null pero si entendemos «único» en este sentido, para referirse a un estilo de SQL unqiue restricción entonces estamos hablando de algo que puede incluir valores nulos y por lo tanto no es una «clave» en todo! Así sleske es correcto, si la «clave única» se entiende «clave candidata». Yo recomendaría evitar el término «clave única» completamente. Es demasiado abierto a la interpretación.
    • no porque una clave no puede cubrir algunos filas por ser null.
    • No estoy seguro de lo que quieres decir. Una de las claves es que no aceptan valores null por definición. Si una restricción unique incluye las columnas que permiten valores nulos, entonces no es una clave.
    • no, porque no es necesario para una clave para tener una entrada en cada fila. Es posible que una clave para que sólo identificar las filas de un subconjunto del total de filas en la tabla.
    • Usted no está hablando sobre el modelo relacional, pero RE-modelado de conceptos. Desde el contexto de mi hipótesis es que estamos hablando de las claves en el modelo relacional. Una clave en el modelo relacional es muy precisamente definidos como un conjunto de atributos que unqiuely identifica cada tupla de una relación. Para la confirmación de ver el Diccionario de Base de datos Relacional, Codd los papeles o su libro, o cualquier otra base de datos de la teoría de los libros de texto. Esto es fundamental porque cada relación, por definición, tiene al menos una clave y, a menudo más de uno.
    • ¿Cómo sería el modelo de uno a cero o una relación?
    • Esto es un poco off-topic, pero para lo que vale aquí es un ejemplo de un 1 a 0/1 relación en SQL: CREATE TABLE r (x INT not NULL PRIMARY KEY REFERENCIAS s (x), z INT not NULL ÚNICAS REFERENCIAS t (z)); Este es un ejemplo de una tabla con dos llaves. Arbitrariamente uno de ellos puede ser designado como el «principal» de la clave. No importa que uno se llama primaria debido a que todas las claves que sirven para el mismo propósito – para identificar una fila.

Dejar respuesta

Please enter your comment!
Please enter your name here