online - database design software
¿Clave principal frente a restricción única? (16)
Actualmente estoy diseñando una nueva base de datos. En la escuela, siempre aprendimos a poner una clave principal en cada tabla.
Leí un montón de artículos / discusiones / publicaciones de grupos de noticias diciendo que es mejor usar restricciones únicas (también conocido como índice único para algunos db) en lugar de PK.
¿Cuál es tu punto de vista?
publicaciones que dicen que es mejor usar restricción única (también conocido como índice único para algunos db) en lugar de PK
Supongo que el único punto aquí es la misma discusión anterior "claves naturales vs sustitutas", porque los índices únicos y los pk son lo mismo.
traductorio:
publicaciones que dicen que es mejor usar una clave natural en lugar de una clave sustituta
¿Puedes proporcionar referencias a estos artículos?
No veo ninguna razón para cambiar los métodos probados y verdaderos. Después de todo, las claves primarias son una característica de diseño fundamental de las bases de datos relacionales.
Usar UNIQUE para servir el mismo propósito me suena realmente hackish. ¿Cuál es su razón de ser?
Editar: Mi atención acaba de volver a esta antigua respuesta. Tal vez la discusión que leyó con respecto a PK frente a UNIQUE trató con personas que hacen de algo un PK con el único propósito de imponer la singularidad en él. La respuesta a esto es: si es una clave, entonces conviértala en clave; de lo contrario, ÚSELA.
A menos que la tabla sea una tabla temporal para representar los datos mientras usted trabaja en ella, siempre desea poner una clave principal en la tabla y aquí está el motivo:
1 - una restricción única puede permitir valores nulos, pero una clave principal nunca permite valores nulos. Si ejecuta una consulta con una combinación en columnas con valores nulos, elimina esas filas del conjunto de datos resultante porque null no es igual a nulo. Así es como incluso las grandes empresas pueden cometer errores contables y tienen que volver a declarar sus ganancias. Sus consultas no mostraban ciertas filas que deberían haberse incluido en el total porque había valores nulos en algunas de las columnas de su índice único. Shoulda usó una llave primaria.
2 - un índice único se colocará automáticamente en la clave principal, por lo que no tiene que crear uno.
3 - la mayoría de los motores de base de datos colocarán automáticamente un índice agrupado en la clave primaria, lo que hace que las consultas sean más rápidas porque las filas se almacenan contiguamente en los bloques de datos. (Esto puede modificarse para colocar el índice agrupado en un índice diferente si eso acelera las consultas). Si una tabla no tiene un índice agrupado, las filas no se almacenarán contiguamente en los bloques de datos, lo que hace que las consultas más lento porque el cabezal de lectura / escritura debe viajar por todo el disco para recoger los datos.
4: muchos entornos de desarrollo front-end requieren una clave principal para actualizar la tabla o realizar eliminaciones.
Estaba pensando en este problema yo mismo. Si usa un único, dañará el 2. NF. De acuerdo con esto, cada atributo no-pk debe estar dependiendo del PK. El par de atributos en esta restricción única se debe considerar como parte del PK.
Lamento haber respondido a esto 7 años después, pero no quería comenzar una nueva discusión.
He escrito mucho sobre este tema: si lees algo mío, ten en claro que probablemente me refería específicamente a Jet aka MS Access.
En Jet, las tablas se ordenan físicamente en PRIMARY KEY usando un índice agrupado no mantenido (se agrupa en compacto). Si la tabla no tiene PK pero tiene claves candidatas definidas usando restricciones ÚNICAS en columnas NOT NULL, el motor elegirá una para el índice agrupado (si su tabla no tiene un índice agrupado, entonces se llama montón, podría decirse que no es una tabla en absoluto !) ¿Cómo selecciona el motor una clave candidata? ¿Puede elegir uno que incluya columnas que aceptan nulos? Realmente no lo sé El punto es que en Jet la única forma explícita de especificar el índice agrupado para el motor es usar PRIMARY KEY. Por supuesto, hay otros usos para PK en Jet, por ejemplo, se usará como clave si se omite uno de una declaración FOREIGN KEY en SQL DDL, pero de nuevo, por qué no ser explícito.
El problema con Jet es que la mayoría de las personas que crean tablas desconocen o no se preocupan por los índices agrupados. De hecho, la mayoría de los usuarios (apuesto) colocan una columna Autonumber autoincrement en cada tabla y definen la PRIMARY KEY únicamente en esta columna mientras no ponen restricciones exclusivas en la clave natural y las claves candidatas (si una columna autoincrement puede considerarse como una clave sin exponerlo a los usuarios finales es otra discusión en sí misma). No entraré en detalles sobre los índices agrupados aquí, pero basta con decir que la IMO, una columna de autoincremento, raramente es la opción ideal.
Sea cual sea su motor SQL, la elección de PRIMARY KEY es arbitraria y específica del motor. Por lo general, el motor aplicará un significado especial al PK, por lo tanto, debe averiguar qué es y utilizarlo para su ventaja. Animo a las personas a usar restricciones NO NULAS ÚNICAS con la esperanza de que den mayor consideración a todas las claves candidatas, especialmente cuando han elegido usar columnas ''autonumber'' que (no deberían) tener ningún significado en el modelo de datos. Pero prefiero que las personas elijan una clave bien considerada y utilicen PRIMARY KEY en lugar de ponerla en la columna de autoincrement por costumbre.
¿Deberían todas las tablas tener un PK? Digo que sí, porque de lo contrario, significa que al menos se está perdiendo una ligera ventaja de que el motor proporciona el PK y, en el peor de los casos, no tiene integridad de datos.
BTW Chris OC hace un buen punto aquí acerca de las tablas temporales, que requieren claves primarias secuenciadas (minúsculas) que no pueden implementarse mediante simples restricciones PRIMARY KEY (palabras clave SQL en mayúsculas).
Las claves primarias se deben usar en situaciones en las que establecerá relaciones desde esta tabla a otras tablas que harán referencia a este valor. Sin embargo, dependiendo de la naturaleza de la tabla y de los datos a los que está pensando aplicar la restricción exclusiva, es posible que pueda usar ese campo en particular como clave primaria natural en lugar de tener que establecer una clave sustituta. Por supuesto, sustituto vs llaves naturales son una otra discusión. :)
Las claves únicas se pueden usar si no se establece ninguna relación entre esta tabla y otras tablas. Por ejemplo, una tabla que contiene una lista de direcciones de correo electrónico válidas con las que se compararán antes de insertar un nuevo registro de usuario o algo así. O se pueden usar claves únicas cuando tiene valores en una tabla que tiene una clave principal pero también debe ser absolutamente único. Por ejemplo, si tiene una tabla de usuarios que tiene un nombre de usuario. No querrá utilizar el nombre de usuario como clave principal, pero también debe ser único para poder utilizarlo con fines de inicio de sesión.
Necesitamos hacer una distinción aquí entre construcciones lógicas y construcciones físicas, y de manera similar entre teoría y práctica.
Para empezar: desde una perspectiva teórica, si no tiene una clave principal, no tiene una tabla. Es así de simple. Entonces, su pregunta no es si su tabla debe tener una clave principal (por supuesto que debería), sino cómo la etiqueta dentro de su RDBMS.
En el nivel físico, la mayoría de los RDBMS implementan la restricción de clave principal como un índice único. Si el RDBMS elegido es uno de estos, probablemente no haya mucha diferencia práctica entre designar una columna como clave principal y simplemente poner una restricción única en la columna. Sin embargo, una de estas opciones captura su intención y la otra no. Entonces, la decisión es obvia.
Además, algunos SGBDR hacen que las funciones adicionales estén disponibles si las claves principales están etiquetadas adecuadamente, como la diagramación y el soporte semiautomático de restricción de clave externa.
Cualquier persona que le pida que use Restricciones únicas en lugar de Llaves primarias como regla general debería proporcionar una buena razón.
Presento que puede necesitar ambos. Las claves primarias por naturaleza deben ser únicas y no anulables. A menudo son claves indirectas ya que los enteros crean uniones más rápidas que los archivos de caracteres y especialmente que múltiples combinaciones de caracteres de campo. Sin embargo, dado que a menudo se autogeneran, no garantizan la exclusividad del registro de datos excluyendo la propia identificación. Si su tabla tiene una clave natural que debe ser única, debe tener un índice único para evitar la entrada de datos de duplicados. Este es un requisito básico de integridad de datos.
Editado para agregar: también es un problema real que los datos del mundo real a menudo no tengan una clave natural que realmente garantice la unicidad en una estructura de tabla normalizada, especialmente si la base de datos está centrada en las personas. Los nombres, incluso el nombre, la dirección y el número de teléfono combinados (piense en padre e hijo en la misma práctica médica) no son necesariamente únicos.
Sería una desnormalización muy rara que haría que quisieras tener una tabla sin una clave primaria. Las claves primarias tienen restricciones únicas automáticamente por su naturaleza como PK.
Se usará una restricción única cuando desee garantizar la exclusividad en una columna ADICIONAL a la clave principal.
La regla de tener siempre un PK es buena.
Siempre debes tener una clave principal.
Sin embargo, sospecho que su pregunta es un poco confusa, y en realidad quiere preguntar si la clave principal siempre debe ser un número generado automáticamente (también conocido como clave sustituta), o algún campo único que sea información real significativa (también conocida como natural clave), como SSN para personas, ISBN para libros, etc.
Esta pregunta es una guerra religiosa ancestral en el campo DB.
Mi opinión es que las claves naturales son preferibles si son únicas y nunca cambian. Sin embargo, debe tener cuidado, incluso algo aparentemente estable como el SSN de una persona puede cambiar bajo ciertas circunstancias.
Una clave principal es realmente solo una clave candidata que no permite NULL. Como tal, en términos de SQL, no es diferente de cualquier otra clave única.
Sin embargo, para nuestros RDBMS no teóricos, debe tener una Clave principal: nunca escuché que argumentara lo contrario. Si esa clave principal es una clave sustituta , entonces también debe tener restricciones únicas sobre la (s) clave (s) natural (es) .
Lo importante es que debe tener restricciones únicas para todas las claves candidatas (ya sean naturales o suplentes). A continuación, debe elegir el que sea más fácil de referencia en una clave externa para ser su clave principal *.
También debe tener un índice agrupado *. esta podría ser su clave principal o una clave natural, pero no es obligatorio. Debe elegir su índice agrupado en función del uso de consulta de la tabla. En caso de duda, la clave principal no es una mala primera opción.
Aunque técnicamente solo es necesario referirse a una clave única en una relación de clave externa, se acepta como práctica estándar favorecer en gran medida la clave principal. De hecho, no me sorprendería que algunos RDBMS solo permitan referencias a claves principales.
Editar: Se ha señalado que el término de Oracle de "tabla agrupada" e "índice agrupado" son diferentes al servidor Sql. El equivalente de lo que estoy hablando en Oracle-ese es una tabla ordenada por índice y se recomienda para tablas OLTP, que, creo, sería el foco principal de las preguntas SO. Supongo que si usted es responsable de un gran almacén de datos OLAP, ya debería tener sus propias opiniones sobre el diseño y la optimización de la base de datos.
Una clave principal es solo una clave candidata (restricción única) seleccionada para un tratamiento especial (creación automática de índices, etc.).
Espero que las personas que discuten contra ellos no vean ninguna razón para tratar una clave de forma diferente a otra. Ahí es donde estoy parado.
[Editar] Aparentemente no puedo comentar ni siquiera en mi propia respuesta sin 50 puntos.
@chris: No creo que haya ningún daño. "Clave principal" es en realidad solo azúcar sintáctico. Los uso todo el tiempo, pero ciertamente no creo que sean necesarios. Se requiere una clave única, sí, pero no necesariamente una clave principal.
Usualmente uso tanto PK como UNIQUE KEY. Porque incluso si no denota PK en su esquema, siempre se genera uno para usted internamente. Es cierto tanto para SQL Server 2005 como para MySQL 5.
Pero no uso la columna PK en mis SQL. Es para fines de gestión como ELIMINAR algunas filas erróneas, encontrar espacios entre los valores de PK si está configurado en AUTO INCREMENT. Y, tiene sentido tener un PK como números, no un conjunto de columnas o matrices de caracteres.
el problema es que una clave principal puede ser una o más columnas que identifican de manera única un solo registro de una tabla, donde una Restricción única es solo una restricción en un campo que permite solo una instancia única de cualquier elemento de datos en una tabla.
PERSONALMENTE, utilizo GUID o BIGINTS autoincrementables (Identity Insert para SQL SERVER) para claves únicas utilizadas para referencias cruzadas entre mis tablas. Luego usaré otros datos para permitirle al usuario seleccionar registros específicos.
Por ejemplo, tendré una lista de empleados y un GUID adjunto a cada registro que uso detrás de escena, pero cuando el usuario selecciona un empleado, los selecciona basándose en los siguientes campos: Apellido + Nombre + EmployeeNumber.
Mi clave principal en este escenario es Apellido + Nombre + EmpleadoNúmero mientras que la clave única es el GUID asociado.
CLAVE PRIMARIA
1. Nulo No permite valores nulos. Debido a esto, referimos PRIMARY KEY = UNIQUE KEY + Not Null CONSTRAINT. 2. ÍNDICE Por defecto, agrega un índice agrupado. 3. LÍMITE Una tabla puede tener solo una columna PRIMARY KEY [s].
LLAVE UNICA
1. Nulo permite el valor nulo. Pero solo un valor nulo 2. ÍNDICE Por defecto, agrega un índice ÚNICO no agrupado. 3. LÍMITE Una tabla puede tener más de una columna de clave ÚNICA [s].
Si planea usar LINQ-to-SQL, sus tablas requerirán claves principales si planea realizar actualizaciones, y requerirán una columna de timestamp si planea trabajar en un entorno desconectado (como pasar un objeto a través de un servicio WCF). solicitud).
Si te gusta .NET, PK y FK son tus amigos.