software - database diagram tool
¿Debería cada mesa tener una clave primaria? (13)
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 estoy sintiendo un poco culpable por ello. ¿Debería?
¿Debería cada mesa tener una clave primaria?
EDITAR: Está bien, está bien ... ¡He creado la clave principal! ¿Eres feliz ahora? :)
¿Alguna vez necesitarás unir esta tabla a otras tablas? ¿Necesita una manera de identificar de forma única 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 esa Sally Smith y almacenará esa información en tablas relacionadas, ya que la persona puede tener varios teléfonos. , correos electrónicos, etc. Supongamos que Sally Smith se casa con John Jones y se convierte en Sally Jones. Si no tiene una llave artificial en la mesa, cuando actualiza el nombre, acaba de cambiar 7 Sally Smiths a 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 saber cuál vive Sally Smith en Chicago y cuál vive en Los Ángeles?
Usted dice que no tiene una clave natural, por lo tanto, tampoco tiene ninguna combinación de campo para hacerla única, esto hace que la clave artística sea crítica.
He encontrado que en cualquier momento 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, sigo prefiriendo una clave artificial y un índice único en la clave natural. Te arrepentirás más tarde si no pones uno.
Casi siempre que he creado una tabla sin una clave principal, pensando que no necesitaría una, terminé volviendo y agregando una. Ahora creo incluso mis tablas de combinación con un campo de identidad generado automáticamente que uso como clave principal.
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.
Es una buena práctica tener un PK en cada mesa, pero no es un deber. Lo más probable es que necesite un índice único, y / o un índice agrupado (que es PK o no) dependiendo de su necesidad.
Consulte las secciones Claves primarias e Índices agrupados en los Libros en línea (para SQL Server)
"Las restricciones de PRIMARY KEY identifican la columna o el conjunto de columnas que tienen valores que identifican de forma ú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 primaria. se recomienda utilizar una pequeña columna de enteros como clave principal. Cada tabla debe tener una clave principal. Una columna o combinación de columnas que califican como un valor de clave principal se denomina clave candidata " .
Pero luego revisa esto también: http://www.aisintl.com/case/primary_and_foreign_key.html
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 de base de datos original no contenía TECLAS PRIMARIAS en algunas tablas. Así que, por favor, no permitas que otras personas sufran debido a tu mal diseño. Siempre es buena idea tener claves primarias en las tablas.
Excepto por unos pocos casos muy raros (posiblemente una tabla de relaciones de muchos a muchos, o una tabla que utiliza temporalmente para cargar en grandes cantidades grandes cantidades de datos), me gustaría decir lo siguiente:
Si no tiene una clave principal, ¡no es una tabla!
Bagazo
Para que sea una prueba de futuro realmente deberías. Si quieres replicarlo necesitarás uno. Si quieres unirte 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.
Respuesta corta: si .
Respuesta larga:
- Necesitas tu mesa para poder unirse en algo.
- Si desea que su tabla esté agrupada, necesita algún tipo de clave principal.
- Si el diseño de su mesa no necesita una clave principal, reconsidere su diseño: lo más probable es que 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, por lo que crea una columna adicional a la que no tiene acceso.
Tenga en cuenta que una clave principal puede ser compuesta.
Si tiene una tabla de enlaces de muchos a muchos, cree 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 como cualquier clave principal implica la creación de un índice único, debe declararlo y obtener tanto coherencia lógica como rendimiento.
Vea este artículo en mi blog para saber por qué siempre debe crear un índice único en datos únicos:
PD: hay algunos casos muy especiales en los que no necesita una clave principal.
Principalmente incluyen tablas de registro que no tienen índices por razones de rendimiento.
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 pueda saber qué fila necesita actualizarse o eliminarse. La práctica general debe ser tener una clave primaria o un clúster de clave principal. Yo personalmente prefiero el primero.
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 de sql / ddl sin formato y no se agregó ninguna clave principal
Siempre es mejor tener una clave primaria. De esta manera, cumple la primera forma normal y le permite continuar por 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 dañará si hay una clave principal
Siempre tengo una clave principal, aunque al principio no tengo un propósito en mente todavía. Ha habido algunas veces en las que eventualmente necesito un PK en una tabla que no tiene uno y siempre es más problemático ponerlo más tarde. Creo que hay más de una ventaja al incluir siempre uno.
Solo agréguelo, lo lamentará más tarde cuando no lo haya hecho (selección, eliminación, vinculación, etc.)