¿Demasiadas a muchas tablas tienen una clave principal?

Question

Si tengo dos objetos que tienen una relación de varios a varios, normalmente los modelaría en el esquema de mi 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 unión") tener una clave principal propia (entero de auto incremento)?

Por ejemplo, podría tener las tablas A y B, cada una con una ID, y una tabla llamada A_B que tiene una tupla de clave foránea de (A_ID, B_ID). Pero, ¿debería A_B tener una columna de identificación autoincrementada de tecla principal propia o no?

¿Cuáles son las ventajas y desventajas de agregarlo? Personalmente me gustan las claves naturales para uniones de muchos a muchos. Pero, ¿qué beneficio adicional agregaría una clave principal?

Answer 1

Estoy de acuerdo con todo lo que dijo Oded excepto

"No puede razonablemente ser utilizado como una clave externa tampoco."

En este caso, es una elección su veneno, la tabla de mapeo puede ser un padre, es solo cuestión de que el niño use un FK multicolumna o no.

Tome una simple caja de coche y color. Cada año Auto Makers tiene una cierta paleta de colores y cada modelo solo viene en un número limitado de esos colores. Muchos - Muchos :: Colores para coches modelos

Así que ahora diseña la tabla de pedidos donde se almacenan las órdenes de autos nuevos.Claramente, el Color y el Modelo estarán en la tabla de Pedidos. Si crea un FK en cada una de esas tablas, la base de datos permitirá seleccionar una combinación incorrecta de modelo/color. (Por supuesto que puede aplicar esto con el código, no puede hacerlo declarativamente). Si hace que el padre sea la tabla many: much, solo obtendrá las combinaciones que se han especificado.

SO ¿preferiría tener un FK multicolumna y apuntar a un PK construido tanto con ModelID como con ColorID o desea una sola columna FK?

Elija su veneno.

EDITAR

Pero si no es un padre de algo, no hay ninguna tabla necesita una clave sustituta.

Answer 2

Dicha clave sustituta no agrega nada excepto por encima.

Utilice las teclas naturales, conviértalas en una clave primaria compuesta si le importa la duplicación en esta tabla.

Para ampliar:

En la aplicación, esta tecla no tendrá ningún sentido y no se usarán.

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 foránea.

Answer 3

Realmente no proporciona nada útil. Tenga en cuenta el propósito de una clave, que es referirse de forma única a "algo". Una tabla de asociación como esta no es en sí misma "algo", sino que es una estructura de persistencia para otros dos "algo" 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 comercial), por lo que nunca (debería) haber una razón para referirse a él por su propia identificación.

Answer 4

Lo he hecho en ambos sentidos. Algunas veces es beneficioso agregar una característica más adelante. Por ejemplo, si alguna vez hubo una fila en la que una fila contenía algo más que las dos identificaciones. Si no le falta espacio, pondría uno allí porque no puede doler. A veces puede interferir con herramientas ORM como hibernate o ADO.NET, pero eso es menor.

Para resumir ... PROS 1. Permite un posible crecimiento futuro.

CONS 1. Espacio 2. Confunde algunas herramientas ORM.

Answer 5

El término "join table" se usa a menudo, pero no creo que lo haya visto nunca definido o explicado correctamente. Personalmente, evito usar ese término. Según tengo entendido, 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 deberían ser muy similares a las de cualquier otra tabla. Pregúntese qué dependencias necesita para hacer cumplir, qué es único e irreductible. Seleccione las teclas según los criterios de Familiaridad, Estabilidad y Simplicidad. Agregue claves sustitutivas solo cuando tenga una buena razón para hacerlo.