database - soporta - ¿Muchas tablas deberían tener una clave principal?
relacion uno a uno oracle (5)
El término "unirse a la tabla" se usa a menudo, pero creo que nunca lo he visto correctamente definido o explicado. Personalmente evito usar ese término. Como lo entiendo, una "tabla de unión" significa cualquier tabla con dos claves externas (¿o posiblemente más de dos?).
Creo que los criterios para seleccionar claves en una tabla con más de una clave externa deben ser muy parecidos a los de cualquier otra tabla. Pregúntese qué dependencias necesita cumplir, qué es único e irreductible. Seleccionar claves en los criterios de familiaridad, estabilidad y simplicidad. Agregue claves sustitutas solo cuando tenga una buena razón para hacerlo.
Si tengo dos objetos que tienen una relación de muchos a muchos, normalmente los modelaré en mi esquema de base de datos con una tabla de muchos a muchos para relacionar los dos. Pero, ¿debería esa tabla de muchos a muchos (o "tabla de combinación") tener una clave primaria propia (entero incrementado automáticamente)?
Por ejemplo, podría tener las tablas A y B, cada una con un ID, y una tabla llamada A_B que tiene una tupla de clave externa de (A_ID, B_ID). Pero, ¿debería A_B tener una columna de ID auto-incrementada de clave primaria propia o no?
¿Cuáles son las ventajas y desventajas de agregarlo? Personalmente, me gustan las claves naturales para las combinaciones de muchos a muchos. Pero, ¿qué beneficio agregado agregaría una clave primaria?
Estoy de acuerdo con todo lo que dijo Oded excepto
"Tampoco se puede utilizar razonablemente como clave externa".
En este caso, es una elección su veneno, la tabla de mapeo absolutamente puede ser un padre, es solo una cuestión del niño que usa un FK de varias columnas o no.
Tomemos un caso sencillo de coche y color. Cada año, los fabricantes de autos tienen una cierta gama de colores y cada modelo solo viene en un número limitado de esos colores. Muchos - Muchos :: Colores para modelos de coches
Así que ahora diseñe la tabla de pedidos donde se almacenan los pedidos de autos nuevos. Claramente, el color y el modelo estarán en la tabla de pedidos. Si crea un FK para cada una de esas tablas, la base de datos permitirá que se seleccione una combinación de modelo / color incorrecta. (Por supuesto que puede hacer cumplir esto con el código, no puede hacerlo de manera declarativa). Si hace que la tabla principal sea la tabla de muchos: muchos, solo obtendrá las combinaciones que se han especificado.
Entonces, ¿preferiría tener un FK de varias columnas y apuntar a un PK integrado tanto en ModelID como en ColorID o desea un FK de una sola columna?
Elige tu veneno.
EDITAR
Pero si no es un padre de algo, ninguna tabla necesita una clave sustituta.
Lo he hecho de ambas maneras. A veces es beneficioso para agregar una característica en el camino. Por ejemplo, si alguna vez hubo un momento en que una fila en la tabla contendría algo más que solo los 2 id. Si no te falta espacio, pondría uno ahí solo porque no puede doler. A veces puede interferir con herramientas de ORM como hibernar o ADO.NET, pero eso es menor.
Así que para resumir ... PROS 1. Permite un potencial crecimiento futuro.
CONTRAS 1. Espacio 2. Confunde algunas herramientas ORM.
Realmente no proporciona nada útil. Tenga en cuenta el propósito de una clave, que es referirse únicamente a "algo". Una tabla de asociación como esta no es por sí misma "algo" sino que es más bien una estructura de persistencia para otras dos "cosas" que ya tienen claves. Fuera del medio de persistencia (la base de datos) no tiene un significado y ni siquiera debería existir o ser conocido (como en el dominio de negocios), por lo que nunca debería haber una razón para referirse a él. su propia identificación.
Tal clave sustituta no agrega nada, excepto los gastos generales.
Use las claves naturales, conviértalas en una clave primaria compuesta si le interesa la duplicación en esta tabla.
Expandir:
En la aplicación, esta clave no tendrá sentido y no se utilizará.
En la base de datos, no tendrá ninguna función, ya que no se puede usar razonablemente en una consulta para ningún tipo de resultado significativo.
Tampoco se puede usar razonablemente como una clave externa.