>Hola!
>
>Gracias por su respuesta.
>Segun lo que entendi de su solucion (en el caso de la facturas) es que con
>el fin de que dos o mas registros padres puedan tener registros hijos en comun
>estos registros (que en este caso serian los productos comprados) deben ser almacenados en una tercera tabla, la cual seria la tabla ''hija de la tabla de
>detalles de las facturas en una relacion de 1 a muchos entre las tablas.
>Aun si esta fuera la solucion correcta (en mi caso), siempre tendria que crear una una rutina que me mantenga actualizados los registros entre las tablas, es esto comun entre sistemas?
>Ahi me disculpa si soy tan 'romo'
>Adios

No, la misma tabla de "detalles de factura" ya sería la tercera tabla que mencioné antes.

Un detalle de factura tiene un solo producto, así que, si ya tienes una tabla "detalle de factura', no hay problema adicional.

El problema muchos-a-muchos surge cuando piensas sólo en las relaciones entre facturas y productos. Una factura puede contener varios productos, y un producto puede aparecer en muchas facturas.

La tabla "detalles de factura" es, ya, la solución.


Otro ejemplo "muchos-a-muchos": registro de estudiantes en la universidad.

Un estudiante puede inscribirse en muchas materias, y en una materia, se inscriben varios estudiantes. Por lo tanto, no puedes asignar la materia en un campo de la tabla "estudiantes", y tampoco puedes asignar el estudiante en un campo de la tabla "materias". Necesitas una tercera tabla para resolver la relación muchos-a-muchos. En este caso, la tercera materia podría llamarse "registros" (registro de estudiantes).

No sé si todo esto es suficientemente claro...

Hilmar.