Tablas de asociaciones de muchos a muchos: ¿Es habitual incluir columnas adicionales en estas tablas?

Question

Hemos encontrado la siguiente situación en nuestra base de datos. Tenemos la tabla 'A' y la tabla 'B' que tienen una relación M2M. La tabla de asociación se llama 'AB' y contiene una columna FK para la tabla 'A' y una columna FK para la tabla 'B'. Ahora hemos identificado la necesidad de almacenar datos adicionales sobre esta asociación. Por ejemplo, una fecha en que se produjo la asociación, quién hizo la asociación, etc. Hemos decidido colocar estas columnas adicionales en la tabla de asociación 'AB'. Sin embargo, algo me dice que esto está mal visto por los puristas de bases de datos. Por otro lado, no tiene sentido para nosotros crear una tabla adicional para almacenar estos datos asociados.

¿Cuál es la opinión predominante sobre esto?

Answer 1

No veo nada de malo en eso. Si la información es sobre la asociación en sí, parece ser el lugar correcto y correcto para almacenarla.

Si crea una nueva tabla para almacenar esto, simplemente se relacionará con la tabla de asociación de todos modos una a una. Esto esencialmente sería simplemente extender la tabla de asociación.

Answer 2

Si los datos pertenecen realmente a la relación en lugar de a una de las entidades individuales ... entonces sí, póngalo en la tabla dinámica.

Answer 3

Tiene más sentido almacenar datos sobre la asociación en la propia tabla de asociación. Nunca escuché que alguien frunciera el ceño ante este método ... en realidad aceleraría el proceso de almacenar esta información en una tabla separada, ya que le ahorrará una combinación para recuperarla.

Answer 4

He hecho esto antes y no creo que haya nada de malo en ello. Si los datos tienen que ver con la relación, como en su caso donde es la fecha en que ocurrió la asociación, y no pertenece específicamente a una tabla u otra, la tabla de asociación es el lugar para ubicarla.

Answer 5

En este diseño, usted está tratando a la asociación como una entidad. Si esa entidad del mundo real, la relación entre las otras dos entidades, tiene sus propios atributos, entonces la tabla que representa esa relación también debe representar los atributos de esa relación.

Si creó una tabla separada, ¿qué entidad del mundo real estaría modelando con esa tabla? ¿Información auxiliar relacionada pero no directamente con la relación entre dos entidades? Eso es difícil de conceptualizar, no parece tener mucho sentido desde el punto de vista del diseño, y casi con seguridad funcionaría peor.

Answer 6

"Sin embargo, algo me dice que esto está mal visto por los puristas de bases de datos".

No me puedo imaginar a ninguna persona que tenga conocimientos de diseño de bases de datos y que fruncir el ceño ante su diseño, si ese diseño es realmente un modelo preciso para la realidad que está tratando.

Answer 7

En this recent answer, defiendo una tabla de enlaces en lugar de una simple relación FK. Uno de los beneficios es cuando la relación comienza a tener más y más datos asociados con ella para que se convierta en una entidad. Específicamente con fechas y cambios efectivos incluso en una jerarquía simple de varios a uno, aún puede tener mucho sentido usar un diseño de tabla de enlaces de muchos a muchos. Obviamente, ya se necesitaba una tabla de enlaces; ahora está claro que existen otros atributos asociados a esa relación.

Por supuesto, resulta que estos son el lugar correcto para poner estos atributos; probablemente experimente algunas dificultades al ponerlos en cualquiera de las tablas, ya sea con normalización o simplemente con semántica incorrecta.Esto también ofrece buenas opciones para la indexación, ya que puede agregar un índice sobre la fecha de vigencia o el estado de la relación a esta tabla relativamente estrecha sin decidir a qué índices debe agregarse en las otras tablas de entidad

No creo cualquier diseñador experimentado de bases de datos se opondría si mostrara el diseño y cómo se utilizan en la práctica sus características y ventajas de diseño. Para mí, no necesitaría una amplia justificación de diseño.