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

Estoy creando una tabla de base de datos y no tengo asignada una clave primaria lógica. Por lo tanto, estoy pensando en dejarlo sin una clave primaria, pero me siento un poco culpable al respecto. ¿Debería?

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


EDITAR: Bien, está bien … ¡He creado la clave principal! ¿Eres feliz ahora? 🙂

Respuesta corta:

Respuesta larga:

  • Necesitas que tu mesa se pueda unir en algo
  • Si desea agrupar su tabla, necesita algún tipo de clave principal.
  • Si el diseño de su mesa no necesita una llave primaria, vuelva a pensar 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 especificaste explícitamente, creando así una columna adicional a la que no tienes acceso.

Tenga en cuenta que una clave principal puede ser compuesta.

Si tiene una tabla de enlaces muchos a muchos, puede crear la clave principal en todos los campos implicados en el enlace. Por lo tanto, se asegura de que no tenga 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 crear 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:

  • Hacer un índice ÚNICO

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.

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 .

Según lo manifestado por otros, hay algunas razones para no tener una clave principal, pero la mayoría no se verá perjudicada si hay una clave principal

Prácticamente en cualquier momento que he creado una tabla sin una clave principal, pensando que no la necesitaría, he terminado 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.

Excepto por algunos casos muy raros (posiblemente una tabla de relaciones de muchos a muchos, o una tabla que utiliza temporalmente para cargar grandes cantidades de datos), me gustaría ir con el dicho:

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

Bagazo

¿Alguna vez necesitarás unirte a esta mesa en otras mesas? ¿Necesita una forma única de identificar un registro? 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. Puede que no haya una clave natural porque necesita las direcciones, correos electrónicos, números de teléfono, etc. para determinar si esta Sally Smith es diferente de la de Sally Smith y usted almacenará esa información en tablas relacionadas ya que la persona puede tener varios teléfonos, addesses , 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 en la mesa, cuando actualiza el nombre, acaba de cambiar 7 Sally Smiths por Sally Jones, aunque solo uno de ellos se casó y cambió su nombre. Y, por supuesto, en este caso sin una clave artificial, ¿cómo sabe qué vive Sally Smith en Chicago y quién vive en Los Ángeles?

Usted dice que no tiene una clave natural, por lo tanto, no tiene ninguna combinación de campo para hacerla única, esto hace que la clave técnica sea crítica.

He encontrado que cada vez que no tengo una clave natural, una clave artificial es una necesidad absoluta para mantener la integridad de los datos. Si tiene una clave natural, puede usarla como campo clave. Pero personalmente, a menos que la clave natural sea un campo, aún prefiero una clave artificial e índice único sobre la clave natural. Te arrepentirás más tarde si no pones uno.

Solo agrégalo, lo lamentarás más tarde cuando no lo hayas hecho (seleccionar, eliminar, vincular, etc.)

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

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

Las restricciones PRIMARY KEY identifican la columna o el conjunto de columnas que tienen valores que identifican de manera única una fila en una tabla. No hay dos filas en una tabla que puedan tener el mismo valor de clave principal. No puede ingresar NULL para ninguna columna en una clave principal. recomendamos usar una pequeña columna entera como clave principal. Cada tabla debe tener una clave principal. Una columna o combinación de columnas que califican como valor de clave principal se conoce como clave candidata.

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

Sé que para usar ciertas características de gridview en .NET, necesita una clave principal para que gridview sepa qué fila necesita actualizarse / eliminarse. La práctica general debería ser tener una clave principal o un clúster de clave principal. Yo personalmente prefiero el primero.

Siempre tengo una clave principal, incluso si al principio todavía no tengo un propósito en mente para eso. Hubo algunas ocasiones en que eventualmente necesité un PK en una tabla que no tiene uno y siempre es más problemático ponerlo luego. Creo que hay más de una ventaja para incluir siempre uno.

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

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

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

Estoy en el papel de mantener la aplicación creada por el equipo de desarrollo offshore. Ahora estoy teniendo todo tipo de problemas en la aplicación porque el esquema original de la base de datos no contenía las LLAVES PRIMARIAS en algunas tablas. Así que por favor no dejes que otras personas sufran debido a tu diseño pobre. Siempre es una buena idea tener claves primarias en las tablas.