¿Deberían todas y cada una de las tablas tener una clave primaria?

340

Estoy creando una tabla de base de datos y no tengo asignada una clave primaria lógica. Entonces, estoy pensando en dejarlo sin una clave principal, pero me siento un poco culpable por eso. ¿Debería?

¿Deberían todas y cada una de las tablas tener una clave primaria?

database database-design Daniel Silveira
fuente
55
¿Podría darnos más detalles sobre la mesa? Sin embargo, la respuesta es probablemente "sí".
Ryan Bair
77
Sí, todas y cada una de las tablas deben tener clave primaria.
Syed Tayyab Ali

Respuestas:

313

Respuesta corta: sí .

Respuesta larga:

  • Necesitas que tu mesa se pueda unir en algo
  • Si desea que su tabla esté agrupada, necesita algún tipo de clave primaria.
  • Si el diseño de su tabla no necesita una clave principal, reconsidere su diseño: lo más probable es que le falte algo. ¿Por qué mantener registros idénticos?

En MySQL, el motor de almacenamiento InnoDB siempre crea una clave principal si no la especificó explícitamente, lo que crea una columna adicional a la que no tiene acceso.

Tenga en cuenta que una clave primaria puede ser compuesta.

Si tiene una tabla de enlaces de muchos a muchos, crea la clave principal en todos los campos involucrados en el enlace. Por lo tanto, se asegura de no tener dos o más registros que describan un enlace.

Además de los problemas de coherencia lógica, la mayoría de los motores RDBMS se beneficiarán al incluir estos campos en un índice único.

Y dado que cualquier clave primaria implica la creación de un índice único, debe declararlo y obtener consistencia lógica y rendimiento.

Vea este artículo en mi blog para saber por qué siempre debe crear un índice único sobre datos únicos:

PD: Hay algunos casos muy, muy especiales en los que no necesita una clave principal.

Principalmente incluyen tablas de registro que no tienen ningún índice por razones de rendimiento.

Quassnoi
fuente
todavía tienen una clave principal, la clave compuesta
kristof
2
@annakata: deberían tener una clave primaria compuesta
Quassnoi
1
"Y dado que cualquier CLAVE PRIMARIA implica crear un índice ÚNICO" no es cierto para Oracle. Se puede usar un índice no único para aplicar una clave primaria. De hecho, a veces se REQUIERE que las restricciones únicas y PK utilicen índices no únicos.
Stephanie Page
3
Solo un comentario sobre la pregunta retórica "¿Por qué mantener registros idénticos?". Tenga en cuenta que solo agregar una PK no garantizará que no haya duplicación. A menudo, el PK no es visible para el usuario, por lo tanto, lo importante es en los campos visibles, que pueden contener datos duplicados. Dependiendo de su diseño, esto puede ser deseable o no.
Rossco
1
Las llaves no tienen nada que ver con la jobility. Y el argumento de agrupamiento depende de qué DBMS use, y combina consideraciones lógicas y físicas.
Jon Heggland
36

Siempre es mejor tener una clave principal. De esta manera, cumple con la primera forma normal y le permite continuar a lo largo de la ruta de normalización de la base de datos .

Como han dicho otros, hay algunas razones para no tener una clave principal, pero la mayoría no se verá perjudicada si hay una clave principal

Michael Wheeler
fuente
55
@PaulSuart Los datos no siempre tienen que estar en sus formas normales. De hecho, cuando los datos se vuelven enormes, no deberían mantenerse en su forma normal; de lo contrario, acceder a los datos sería terriblemente lento para las consultas que se realizan en uniones de tablas, etc. enorme.
Pacerier
13

Casi siempre que he creado una tabla sin una clave principal, pensando que no la necesitaría, terminé volviendo y agregando una. Ahora creo incluso mis tablas de unión con un campo de identidad generado automáticamente que utilizo como clave principal.

tvanfosson
fuente
12
Una tabla de unión ES una clave principal: una clave compuesta, que consta de las PK de ambos registros que se unen. Por ejemplo, CREATE TABLE PersonOrder (PersonId int, OrderId int, PRIMARY KEY (PersonId, OrderId)).
Keith Williams
3
Sí, pero qué pasa si la tabla de enlaces también tiene un tercer atributo, digamos "OrderDate". ¿Agregarías eso a la clave compuesta también? En mi humilde opinión, no, porque es más reducible y no sirve el carácter no reducible que debería tener una clave primaria.
stevek
13

Excepto por algunos casos muy raros (posiblemente una tabla de relación de muchos a muchos, o una tabla que usa temporalmente para cargar grandes cantidades de datos), diría lo siguiente:

Si no tiene una clave primaria, ¡no es una tabla!

Bagazo

marc_s
fuente
99
Estrictamente hablando, esa oración está mal. Las tablas pueden ser "Ver tablas" creadas por su Idioma de consulta. Un RDBMS está compuesto de relaciones, no de tablas. Esa oración debería decir: "¡Si no tiene una clave primaria, no es una relación!".
stevek
O tal vez, "si no hay claves candidatas, entonces no es una tabla relacional". Pero vea los casos muy raros en los que está bien tener una tabla que no represente una relación.
Walter Mitty
¿Por qué una tabla de varios a varios no tendría una clave principal? Puede crear una clave primaria separada y luego crear un índice único para el sustituto de claves externas. Creo que es mejor tener una clave principal en cada tabla. Incluso en una tabla de carga masiva, es posible que desee identificar por separado una clave primaria que no incluye los datos que se importan, ya que puede ayudarlo a identificar registros duplicados en un proceso ETL. Me parece que cada tabla debe tener una clave principal, incluso si es un poco más de almacenamiento. Una tabla creada por una vista es un subconjunto de una tabla, no una tabla en sí misma.
John Ernest
1
En una tabla de relaciones de muchos a muchos, puede crear una clave primaria compuesta que consista en ambos identificadores de las relaciones.
Jaap
8

¿Alguna vez necesitarás unir esta tabla a otras tablas? ¿Necesita una forma de identificar un registro de forma exclusiva? Si la respuesta es sí, necesita una clave principal. Suponga que sus datos son algo así como una tabla de clientes que tiene los nombres de las personas que son clientes. Es posible que no haya una clave natural porque necesita las direcciones, correos electrónicos, números de teléfono, etc. para determinar si este Sally Smith es diferente de ese Sally Smith y almacenará esa información en tablas relacionadas, ya que la persona puede tener múltiples teléfonos, direcciones , correos electrónicos, etc. Supongamos que Sally Smith se casa con John Jones y se convierte en Sally Jones. Si no tiene una clave artificial sobre la mesa, cuando actualiza el nombre, simplemente cambió 7 Sally Smiths a Sally Jones a pesar de que solo uno de ellos se casó y cambió su nombre.

Dices que no tienes una clave natural, por lo tanto, tampoco tienes ninguna combinación de campo para hacerla única, esto hace que la clave artificial sea crítica.

Siempre que no tengo una clave natural, una clave artificial es imprescindible para mantener la integridad de los datos. Si tiene una clave natural, puede usarla como el campo clave en su lugar. Pero personalmente, a menos que la clave natural sea un campo, todavía prefiero una clave artificial e índice único en la clave natural. Te arrepentirás más tarde si no pones uno.

HLGEM
fuente
7

Simplemente agréguelo, lo lamentará más tarde cuando no lo hizo (selección, eliminación, vinculación, etc.)

raphaëλ
fuente
6

Es una buena práctica tener un PK en cada mesa, pero no es NECESARIO. Lo más probable es que necesite un índice único y / o un índice agrupado (que sea PK o no) dependiendo de su necesidad.

Consulte las secciones Claves principales e índices agrupados en los Libros en línea (para SQL Server)

"Las restricciones de CLAVE PRIMARIA identifican la columna o el conjunto de columnas que tienen valores que identifican de forma exclusiva una fila en una tabla. No hay dos filas en una tabla que puedan tener el mismo valor de clave primaria. No puede ingresar NULL para ninguna columna en una clave primaria. Se recomienda utilizar una columna entera pequeña como clave principal. Cada tabla debe tener una clave primaria. Una columna o combinación de columnas que califican como valor de clave primaria se denomina clave candidata. "

Pero luego vea esto también: http://www.aisintl.com/case/primary_and_foreign_key.html

endo64
fuente
1
Compruebe esto también, sql-server-performance.com/2006/primary-key-index-clustered
endo64
44
Esa página es bastante estúpida. Primero, se necesita una clave principal por razones de rendimiento. Al leer su página, aprendo que agregar una ID a una tabla de libros es inútil porque el texto del libro es único; obviamente, el tipo nunca trabajó con bases de datos, pero también tiene problemas para entender lo que critica. Página escrita que 1) un valor PK hace referencia a una fila 2) puede unir 2 tablas por cualquier conjunto de columnas. No hay contradicción. Es sorprendente que el autor de un artículo académico no entienda lo básico de la teoría relacional.
Federico Razzoli
1
"Primero, se necesita una clave principal por razones de rendimiento" esto es incorrecto, PK no afecta directamente el rendimiento. No tener una PK puede generar muchos problemas (identificar una fila, unir, etc.) pero el rendimiento no es uno de ellos. Cuando crea PK en una tabla, el servidor SQL crea un índice agrupado único, ese índice afecta el rendimiento, no la propia PK. Como ejemplo real, mi tabla tiene un índice agrupado en la columna de fecha y un PK en un campo GUID, porque mis filas deben ordenarse físicamente sobre la columna de fecha en la tabla ya que todas las consultas tienen un rango de fechas (en mi caso).
endo64
Ese índice agrupado es una muestra de la clave primaria, creada por SQL Server y varios otros DBMS. ¿Estás seguro de que es una buena idea usarlo? Por ejemplo, en MySQL, no es por varias razones indocumentadas.
Federico Razzoli
1
Tenga en cuenta que GUID no es un tipo óptimo para PK, en InnoDB. Todos los índices contienen una referencia a la PK, por lo tanto, cuanto mayor sea la PK, mayor será el resto de los índices.
Federico Razzoli
6

No estoy de acuerdo con la respuesta sugerida. La respuesta corta es: NO .

El propósito de la clave primaria es identificar de forma exclusiva una fila en la tabla para formar una relación con otra tabla. Tradicionalmente, se usa un valor entero auto-incrementado para este propósito, pero hay variaciones a esto.

Sin embargo, hay casos, por ejemplo, el registro de datos de series de tiempo, en los que la existencia de dicha clave simplemente no es necesaria y solo ocupa memoria. Hacer una fila única es simplemente ... ¡no es obligatorio!

Un pequeño ejemplo: Tabla A: LogData

Columns:  DateAndTime, UserId, AttribA, AttribB, AttribC etc...

No se necesita clave principal.

Tabla B: Usuario

Columns: Id, FirstName, LastName etc.

La clave primaria (Id) necesaria para ser utilizada como una "clave externa" para la tabla LogData.

Theodore Zographos
fuente
3

Sé que para usar ciertas características de la vista de cuadrícula en .NET, necesita una clave principal para que la vista de cuadrícula sepa qué fila necesita actualizarse / eliminarse. La práctica general debe ser tener una clave primaria o un grupo de claves primarias. Yo personalmente prefiero lo primero.

Tacoman667
fuente
3

Para que sea una prueba de futuro, realmente deberías. Si desea replicarlo, necesitará uno. Si quieres unirlo a otra mesa, tu vida (y la de los pobres tontos que tienen que mantenerla el próximo año) será mucho más fácil.

StewNoble
fuente
Todavía no estoy convencido de que sea necesario, pero "hacerlo porque de lo contrario alguien tendrá que lidiar con las consecuencias más tarde" es suficiente para hacerme errar al lado de hacerlo. Siempre puedo soltar la columna más tarde si parece que vale la pena intentar
reducirla
2

Siempre tengo una clave principal, incluso si al principio todavía no tengo un propósito en mente para ello. Ha habido algunas ocasiones en que eventualmente necesito un PK en una tabla que no tiene uno y siempre es más difícil ponerlo más tarde. Creo que hay más ventajas al incluir siempre uno.

rvarcher
fuente
2

Estoy en el papel de mantener la aplicación creada por el equipo de desarrollo offshore. Ahora tengo todo tipo de problemas en la aplicación porque el esquema original de la base de datos no contenía CLAVES PRIMARIAS en algunas tablas. Por lo tanto, no permita que otras personas sufran debido a su mal diseño. Siempre es una buena idea tener claves primarias en las tablas.

Shiva
fuente
1

En resumen, no. Sin embargo, debe tener en cuenta que ciertas operaciones CRUD de acceso de cliente lo requieren. Para futuras pruebas, tiendo a utilizar siempre claves primarias.

Carpintero rico
fuente
1

Si está utilizando Hibernate, no es posible crear una Entidad sin una clave principal. Estos problemas pueden crear problemas si está trabajando con una base de datos existente que se creó con scripts sql / ddl simples, y no se agregó ninguna clave principal

Schildmeijer
fuente