Many-to-many sin tabla intermedia - ¿es posible?

Question

Tengo dos entidades que generalmente tienen una relación de uno a varios, pero en casos excepcionales debería tener la oportunidad de ser de muchos a muchos. No quiero unirme a las tablas con la tabla intermedia para cada consulta, y supongo que hay patrones preferibles para "raro muchos a muchos", - (quizás con tabla adicional para mtm, con registros duplicados o algo así) . ¿Algunas ideas?

UPD. Bueno, en primer lugar, pienso en la sobrecarga potencial con la tabla intermedia (tal vez lo sobreestimo), el segundo se trata de expresar la semántica del mundo real que, por lo general, los objetos deberían tener una relación uno a muchos.

Answer 1

Una relación "rara de muchos a muchos" sigue siendo una relación M: M, y se debe modelar correctamente. Esto implica crear una tabla intermedia o de asociación que vincule las dos tablas. Sus consultas serán un poco más complejas, pero solo implican una unión adicional. Pero usted tendrá la satisfacción y la admiración de sus compañeros que modeló sus tablas correctamente :)

Randy

Answer 2

En general, no podrá evitar la tabla intermedia. Cualquier cosa que haga para facilitar el caso de uno a muchos, solo le costará más esfuerzo manejar el caso general m: n correcto.

Answer 3

¿Qué pasa con la relación de muchos a muchos? Es la forma más sencilla de resolver el problema, y ​​unir las tablas será muy rápido si los índices están configurados correctamente. Y no se preocupe por el tiempo de codificación: puede factorizar la unión para que solo tenga que escribirla una vez. Si está utilizando un software tipo Linq, puede almacenar subconsultas. Si está creando cadenas de SQL a mano, aún puede almacenar la subconsulta como cadena const en algún lugar de su programa.

Sin embargo, puede evitar la tabla adicional creando dos columnas 'Primary Child' y 'Secondary Child' donde el primario no es NULL y Secundario es NULLable. Si no te importa la posibilidad de múltiples coincidencias, selecciona solo hijo principal. En los casos poco frecuentes en los que sí importa, seleccione ambos niños.

Answer 4

Voy a suponer que su pregunta es sobre bases de datos relacionales (SQL, por ejemplo). Si desea modelar la tabla en una forma "normal", entonces se requiere una tabla intermedia. Pero, sin la restricción de la normalidad, puede modelar su caso con una sola tabla con m * n filas (el resultado de una combinación interna si tuviera su tabla A, tabla intermedia y tabla B. Esto puede ser útil en el almacenamiento de datos operaciones, pero no sugeriría utilizar esta estrategia si la tabla a menudo tuviera filas eliminadas, actualizadas o insertadas.

Answer 5

Si algo suele ser una relación uno a muchos, pero a veces muchos a muchos, entonces es solo una relación de muchos a muchos, no un intermediario transitorio. ¿Cuál es el problema con la tabla intermedia? Estoy asumiendo el rendimiento aquí. He encontrado si utiliza tipos de datos que son rápidos para comparar (enteros, por ejemplo) y los índices correctos, entonces el modelo de muchos a muchos se escalará bastante efectivamente. Si esto todavía es un problema, entonces tal vez considere la revisión de su esquema, por ejemplo, son muchas las entidades de muchas a muchas realmente iguales a las usualmente entidades de uno a muchos o deberían ser tablas separadas todas juntas?

Answer 6

Una forma de evitar la tabla de asociación es hacer que cada una de las tablas principales contenga algo así como un conjunto de entradas con referencias cruzadas en la otra tabla, suponiendo que su DBMS incluso admita dicha construcción. Es infinitamente menos deseable por muchas razones, una de las cuales es que es extremadamente difícil consultar o actualizar la lista correcta automáticamente. esquema

Esquema:

create table t1 (id integer, xref_t2 set(integer), ...other columns...); 
create table t2 (id integer, xref_t1 set(integer), ...other columns...); 

Tenga en cuenta que no hay una forma sencilla de declarar una restricción de integridad referencial para asegurar que los valores en 'xref_t2' son de hecho sigue siendo válido (o escribir un disparador para imponer la restricción)

Mecanismos alternativos como una columna que no admite nulos para las referencias cruzadas ordinarias (una en cada tabla) y una columna que admite nulos para las inusuales referencias cruzadas múltiples (de nuevo, una en cada tabla) siguen sin cumplirse situación más inusual en la que no es una relación 1: 2, sino una relación 1: 3 o 1: 4.

La mejor manera de hacerlo es con una tabla de asociación explícita.

Answer 7

Bueno, primero que todo lo que pienso sobrecarga potencial con mesa intermedia (tal vez yo sobreestimarlo)

Creo que sí. Las uniones indexadas son las bases de datos especialmente buenas.

la segunda se trata de expresar la semántica del mundo real que, por lo general, los objetos deberían tener una relación uno a muchos.

Bueno, esa es la pregunta que no podemos responder sin un ejemplo más concreto: ¿cómo difiere la naturaleza de la habitual relación uno a muchos del 'caso especial' de muchos a muchos? Cuando ocurre una relación de muchos a muchos, ¿la relación es diferente entre una de las asignaciones en particular, y todo lo demás? De ser así, podría tener sentido tener una referencia en fila separada para el mapeo uno, con una tabla de unión para los extra.

Pero si es sólo el mismo tipo de relación - sólo uno que generalmente pero no siempre es uno-a-muchos - entonces sigue siendo una relación de muchos a muchos, y el modelado de otra manera va a hacer una barra para su propia espalda. Usted terminaría con cada consulta teniendo que verificar primero la relación de uno a muchos y luego verificar el número y, que sería más sobrecarga, y sería una consulta mucho más complicada para escribir.