Ayuda con diseño de tablas

Manuel,

Lo que diseñaria yo seria de la siguiente manera...

PROVEEDOR
PRODUCTO
ZONA

Luego haria una relacion de la siguiente manera

PROVEEDOR-PRODUCTO de 1 a MUCHOS
PRODUCTO-ZONA de 1 a MUCHOS.

saludos


<Information>
<Name>Mauricio Morales F</Name>
<Nick>Hero</Nick>
</Information>

"Manuel Vera" escribió en el mensaje
news:

Hola

Tengo 3 tablas principales:

PROVEEDORES
PRODUCTOS
ZONAS

Todas se relacionan entre sí con cardinalidad N><M

Es decir, 1 PROVEEDOR despacha muchos PRODUCTOS
A su vez, 1 PRODUCTO puede ser despachado por varios PROVEEDORES
(esto me crea la tabla PROV_PROD)

Es decir, en 1 ZONA se despachan muchos PRODUCTOS
A su vez, 1 PRODUCTO puede ser despachado en varias ZONAS
(esto me crea la tabla ZONA_PROD)

Es decir, 1 ZONA está cubierta por varios PROVEEDORES
A su vez, 1 PROVEEDOR puede despachar a varias ZONAS
(esto me crea la tabla ZONA_PROV)

En cada una de estas 3 tablas nuevas de relación únicamente existen los
campos clave primaria de las tablas que las originan. No existe ningún
otro
atributo.

Finalmente, se crea entre todas ellas una relación circular:

PROVEEDOR-PRODUCTO
| |
| |
| |
ZONA-|

Las preguntas:
¿puedo crear una nueva relación única de las 3 tablas principales y
eliminar
las otras 3 tablas de relación que hay entre ellas?
¿esto me trae algún beneficio en cuanto a espacio en disco junto con
eficiencia del motor de datos?
¿Alguna sugerencia con el diseño?

La nueva tabla sería algo como:

PROVEEDOR-|
|
|
|
PRODUCTO-(NUEVA RELACION)
{IdProv , IdProd , IdZona}
|
|
|
ZONA-|

Gracias
Manuel

Gracias Mauricio por tu respuesta.
Sin embargo, no me sirve tu propuesta debido a que la regla del negocio me
indica que esas relaciones son N : M , es decir, muchos a muchos.

Ya por lo menos descarte la tabla de relación única debido a la cantidad de
registros que contiene.
Pero estoy interesado en conocer que experiencias tienen los colegas al
haber afrontado este tema.

Saludos
MV

"Mauricio Morales F. (Hero)" escribió en el mensaje
news:

Manuel,

Lo que diseñaria yo seria de la siguiente manera...

PROVEEDOR
PRODUCTO
ZONA

Luego haria una relacion de la siguiente manera

PROVEEDOR-PRODUCTO de 1 a MUCHOS
PRODUCTO-ZONA de 1 a MUCHOS.

saludos


<Information>
<Name>Mauricio Morales F</Name>
<Nick>Hero</Nick>
</Information>

"Manuel Vera" escribió en el mensaje
news:

Hola

Tengo 3 tablas principales:

PROVEEDORES
PRODUCTOS
ZONAS

Todas se relacionan entre sí con cardinalidad N><M

Es decir, 1 PROVEEDOR despacha muchos PRODUCTOS
A su vez, 1 PRODUCTO puede ser despachado por varios PROVEEDORES
(esto me crea la tabla PROV_PROD)

Es decir, en 1 ZONA se despachan muchos PRODUCTOS
A su vez, 1 PRODUCTO puede ser despachado en varias ZONAS
(esto me crea la tabla ZONA_PROD)

Es decir, 1 ZONA está cubierta por varios PROVEEDORES
A su vez, 1 PROVEEDOR puede despachar a varias ZONAS
(esto me crea la tabla ZONA_PROV)

En cada una de estas 3 tablas nuevas de relación únicamente existen los
campos clave primaria de las tablas que las originan. No existe ningún
otro
atributo.

Finalmente, se crea entre todas ellas una relación circular:

PROVEEDOR-PRODUCTO
| |
| |
| |
ZONA-|

Las preguntas:
¿puedo crear una nueva relación única de las 3 tablas principales y
eliminar
las otras 3 tablas de relación que hay entre ellas?
¿esto me trae algún beneficio en cuanto a espacio en disco junto con
eficiencia del motor de datos?
¿Alguna sugerencia con el diseño?

La nueva tabla sería algo como:

PROVEEDOR-|
|
|
|
PRODUCTO-(NUEVA RELACION)
{IdProv , IdProd , IdZona}
|
|
|
ZONA-|

Gracias
Manuel

Holas Manuel

Bueno la idea de tabla de relación unica no es mala, realmente el numero de
registros no es mas grande por tenerla asi (ya que las relaciones han de
existir sea en una tabla o usando relaciones)

dependiendo del funcionamiento de proveedores te podrias comer una tabla en
el diseño original, quiero decir:
El proveedor X distribuye los productos A,B,C y trabaja en las zonas
Z1,Z2...
¿eso implica que en cualquiera de esas zonas va a distribuir cualquiera de
los productos? (pregunta cuasi filosofica pero tiene su miga, igual el
proveedor X distribuye A y B en Z1 pero C en Z2) si la respuesta es que todo
proveedor distribuye todos sus productos en todas sus zonas (bastante
logico) puedes evitarte la relacion productos-zonas ya que está implicita en
proveedor-zonas

asi te quedaria
Proveedores--[ProvZon]--zonas
|
[ProvProd]
|
productos

y una forma mas "logica" de trabajar al no tener que especificar la relacion
entre productos y zonas (que puede llegar a ser muy tediosa y con muchos
registros) , de producto a zona o zona a producto el paso con inners lo
haces rapido y en las tablas relacionadas el numero de elementos no es tan
elevado ya
(Proveedores*mediadeproveedorsporzona)+(proveedores*mediaproductosporproveedor)

eso va sobretodo encarado al manejo final de la aplicacion por los usuarios,
una vez creado todo si aparece un nuevo producto D basta con especificarle
el (o los) proveedor para saber en que zonas estara

pero claro te limita el tema de flexibilidad ya que no puedes tener
proveedores con productos para unas zonas y otros productos en otras, no se
si será critico o no en tu app


"Manuel Vera" escribió en el mensaje
news:

Gracias Mauricio por tu respuesta.
Sin embargo, no me sirve tu propuesta debido a que la regla del negocio me
indica que esas relaciones son N : M , es decir, muchos a muchos.

Ya por lo menos descarte la tabla de relación única debido a la cantidad
de registros que contiene.
Pero estoy interesado en conocer que experiencias tienen los colegas al
haber afrontado este tema.

Saludos
MV

"Mauricio Morales F. (Hero)" escribió en el mensaje
news:

Manuel,

Lo que diseñaria yo seria de la siguiente manera...

PROVEEDOR
PRODUCTO
ZONA

Luego haria una relacion de la siguiente manera

PROVEEDOR-PRODUCTO de 1 a MUCHOS
PRODUCTO-ZONA de 1 a MUCHOS.

saludos


<Information>
<Name>Mauricio Morales F</Name>
<Nick>Hero</Nick>
</Information>

"Manuel Vera" escribió en el mensaje
news:

Hola

Tengo 3 tablas principales:

PROVEEDORES
PRODUCTOS
ZONAS

Todas se relacionan entre sí con cardinalidad N><M

Es decir, 1 PROVEEDOR despacha muchos PRODUCTOS
A su vez, 1 PRODUCTO puede ser despachado por varios PROVEEDORES
(esto me crea la tabla PROV_PROD)

Es decir, en 1 ZONA se despachan muchos PRODUCTOS
A su vez, 1 PRODUCTO puede ser despachado en varias ZONAS
(esto me crea la tabla ZONA_PROD)

Es decir, 1 ZONA está cubierta por varios PROVEEDORES
A su vez, 1 PROVEEDOR puede despachar a varias ZONAS
(esto me crea la tabla ZONA_PROV)

En cada una de estas 3 tablas nuevas de relación únicamente existen los
campos clave primaria de las tablas que las originan. No existe ningún
otro
atributo.

Finalmente, se crea entre todas ellas una relación circular:

PROVEEDOR-PRODUCTO
| |
| |
| |
ZONA-|

Las preguntas:
¿puedo crear una nueva relación única de las 3 tablas principales y
eliminar
las otras 3 tablas de relación que hay entre ellas?
¿esto me trae algún beneficio en cuanto a espacio en disco junto con
eficiencia del motor de datos?
¿Alguna sugerencia con el diseño?

La nueva tabla sería algo como:

PROVEEDOR-|
|
|
|
PRODUCTO-(NUEVA RELACION)
{IdProv , IdProd , IdZona}
|
|
|
ZONA-|

Gracias
Manuel

El problema esta en que necesito esa relación circular que planteo. Resulta
que tengo:
* proveedores que despachan sus productos a todas las zonas
* productos unicos de proveedor y 1 sola zona
* productos de varios proveedores y varias zonas
* zonas que dependiendo de quien despache cual producto tienen un costo de
envio u otro (este no lo plantee en el modelo que pase)

Por ejmplo, siguiendo tu linea de comentario, tu dices:

El proveedor X distribuye los productos A,B,C y trabaja en las zonas
Z1,Z2...

Pero no es asi. Tengo 1 o mas proveedores (no todos) que el producto C, solo
lo despachan en Z2 y no en Z1. Por dar un ejemplo.

Lo que se me estaba ocurriendo ultimamente es que cuando un producto sea
despachado en todas las zonas principales, no se registre la relación entre
productos y zonas. Asi libero espacio.

En fin, ¿alguna otra idea? Mas que nada, necesito un feedback de uds para
encarar otras vistas o visiones del mismo problema. Aunque todavia faltan
muchos más detalles que le dan complejidad al tema.

Saludos y gracias
MV


"Dani Castillo" escribió en el mensaje
news:

Holas Manuel

Bueno la idea de tabla de relación unica no es mala, realmente el numero
de registros no es mas grande por tenerla asi (ya que las relaciones han
de existir sea en una tabla o usando relaciones)

dependiendo del funcionamiento de proveedores te podrias comer una tabla
en el diseño original, quiero decir:
El proveedor X distribuye los productos A,B,C y trabaja en las zonas
Z1,Z2...
¿eso implica que en cualquiera de esas zonas va a distribuir cualquiera de
los productos? (pregunta cuasi filosofica pero tiene su miga, igual el
proveedor X distribuye A y B en Z1 pero C en Z2) si la respuesta es que
todo proveedor distribuye todos sus productos en todas sus zonas (bastante
logico) puedes evitarte la relacion productos-zonas ya que está implicita
en proveedor-zonas

asi te quedaria
Proveedores--[ProvZon]--zonas
|
[ProvProd]
|
productos

y una forma mas "logica" de trabajar al no tener que especificar la
relacion entre productos y zonas (que puede llegar a ser muy tediosa y con
muchos registros) , de producto a zona o zona a producto el paso con
inners lo haces rapido y en las tablas relacionadas el numero de elementos
no es tan elevado ya
(Proveedores*mediadeproveedorsporzona)+(proveedores*mediaproductosporproveedor)

eso va sobretodo encarado al manejo final de la aplicacion por los
usuarios, una vez creado todo si aparece un nuevo producto D basta con
especificarle el (o los) proveedor para saber en que zonas estara

pero claro te limita el tema de flexibilidad ya que no puedes tener
proveedores con productos para unas zonas y otros productos en otras, no
se si será critico o no en tu app


"Manuel Vera" escribió en el mensaje
news:

Gracias Mauricio por tu respuesta.
Sin embargo, no me sirve tu propuesta debido a que la regla del negocio
me indica que esas relaciones son N : M , es decir, muchos a muchos.

Ya por lo menos descarte la tabla de relación única debido a la cantidad
de registros que contiene.
Pero estoy interesado en conocer que experiencias tienen los colegas al
haber afrontado este tema.

Saludos
MV

"Mauricio Morales F. (Hero)" escribió en el mensaje
news:

Manuel,

Lo que diseñaria yo seria de la siguiente manera...

PROVEEDOR
PRODUCTO
ZONA

Luego haria una relacion de la siguiente manera

PROVEEDOR-PRODUCTO de 1 a MUCHOS
PRODUCTO-ZONA de 1 a MUCHOS.

saludos


<Information>
<Name>Mauricio Morales F</Name>
<Nick>Hero</Nick>
</Information>

"Manuel Vera" escribió en el mensaje
news:

Hola

Tengo 3 tablas principales:

PROVEEDORES
PRODUCTOS
ZONAS

Todas se relacionan entre sí con cardinalidad N><M

Es decir, 1 PROVEEDOR despacha muchos PRODUCTOS
A su vez, 1 PRODUCTO puede ser despachado por varios PROVEEDORES
(esto me crea la tabla PROV_PROD)

Es decir, en 1 ZONA se despachan muchos PRODUCTOS
A su vez, 1 PRODUCTO puede ser despachado en varias ZONAS
(esto me crea la tabla ZONA_PROD)

Es decir, 1 ZONA está cubierta por varios PROVEEDORES
A su vez, 1 PROVEEDOR puede despachar a varias ZONAS
(esto me crea la tabla ZONA_PROV)

En cada una de estas 3 tablas nuevas de relación únicamente existen los
campos clave primaria de las tablas que las originan. No existe ningún
otro
atributo.

Finalmente, se crea entre todas ellas una relación circular:

PROVEEDOR-PRODUCTO
| |
| |
| |
ZONA-|

Las preguntas:
¿puedo crear una nueva relación única de las 3 tablas principales y
eliminar
las otras 3 tablas de relación que hay entre ellas?
¿esto me trae algún beneficio en cuanto a espacio en disco junto con
eficiencia del motor de datos?
¿Alguna sugerencia con el diseño?

La nueva tabla sería algo como:

PROVEEDOR-|
|
|
|
PRODUCTO-(NUEVA RELACION)
{IdProv , IdProd , IdZona}
|
|
|
ZONA-|

Gracias
Manuel

Tal como lo planteas entonces si que necesitas la relacion y no con 3 tablas
extra de relacion sino con unica tabla, me explico:

necesitas al menos un dato extra (precio de envio del proveedor X producto Y
en la zona Z) ese dato "solo" lo puedes tener en una tabla que relacione las
3 cosas

prodprovzon: idprov,idzona,idprod,precioenvio

eso seria el esquema mas sencillo (y como te digo no tan costoso dado que en
cualquier caso ha de existir la relacion), si quieres reducir esa tabla
podrias usar algunas auxiliares (siguiendo el modelo anterior) que indicaran
como dices productos genericos de un proveedor que distribuye en todas sus
zonas , pero enrevesaria bastante el tratamiento posterior de esa
informacion (yo mas bien haria eso programado, una marca de "en todas las
zonas" que luego simplemente replicara el registro varias veces...)

depende mucho de la carga real de datos que vayas a tener, quiero decir, si
el caso mas habitual va a ser variacion de precios por zonas y productos
"particulares" de cada zona, ese esquema es el mejor

si lo mas habitual (digamos un 90%) va a ser que el proveedor de todos sus
productos en todos lados, entonces creas las tablas auxiliares

un caso particular podria ser tener:
proveedor-provzonaszonas (marcando las zonas principales de
distribucion)
|
provprodzonas: esta seria la anterior pero con la particularidad de que
"zona=null" indicaria "todas las zonas donde trabaja"
|
productos

te evitas una tabla y bastantes datos pero creo que complica luego la
gestion (y se sale algo de un tratamiento standar del problema)

De todas formas yo optaria por la segunda solucion que das (la primera q
digo aqui , tabla de relacion unica con los 3 id's y el precio) y luego
montaria las simplificaciones por encima (funciones de asignar a todas las
zonas con el mismo precio un producto por ejemplo)

¿tan critica es la memoria? no se de cuantos productos-distribuidores-zonas
estamos hablando pero piensa que las soluciones para ahorrar sitio suelen
repercutir en complicacion despues en las sentencias sql , y con muchos
registros eso te afectará al rendimiento (aparte de que uno puede volverse
loco teniendo demasiados casos particulares a la hora de programar filtros y
busquedas por ejemplo) , la tabla unica de relacion entre las 3 tiene como
ventaja la simplicidad (un inner de las 3 tablas y esa te da un listado de
"todo" ) y la simplicidad suele ser buena en estos casos :-)


"Manuel Vera" escribió en el mensaje
news:

El problema esta en que necesito esa relación circular que planteo.
Resulta que tengo:
* proveedores que despachan sus productos a todas las zonas
* productos unicos de proveedor y 1 sola zona
* productos de varios proveedores y varias zonas
* zonas que dependiendo de quien despache cual producto tienen un costo de
envio u otro (este no lo plantee en el modelo que pase)

Por ejmplo, siguiendo tu linea de comentario, tu dices:

El proveedor X distribuye los productos A,B,C y trabaja en las zonas
Z1,Z2...

Pero no es asi. Tengo 1 o mas proveedores (no todos) que el producto C,
solo lo despachan en Z2 y no en Z1. Por dar un ejemplo.

Lo que se me estaba ocurriendo ultimamente es que cuando un producto sea
despachado en todas las zonas principales, no se registre la relación
entre productos y zonas. Asi libero espacio.

En fin, ¿alguna otra idea? Mas que nada, necesito un feedback de uds para
encarar otras vistas o visiones del mismo problema. Aunque todavia faltan
muchos más detalles que le dan complejidad al tema.

Saludos y gracias
MV


"Dani Castillo" escribió en el mensaje
news:

Holas Manuel

Bueno la idea de tabla de relación unica no es mala, realmente el numero
de registros no es mas grande por tenerla asi (ya que las relaciones han
de existir sea en una tabla o usando relaciones)

dependiendo del funcionamiento de proveedores te podrias comer una tabla
en el diseño original, quiero decir:
El proveedor X distribuye los productos A,B,C y trabaja en las zonas
Z1,Z2...
¿eso implica que en cualquiera de esas zonas va a distribuir cualquiera
de los productos? (pregunta cuasi filosofica pero tiene su miga, igual el
proveedor X distribuye A y B en Z1 pero C en Z2) si la respuesta es que
todo proveedor distribuye todos sus productos en todas sus zonas
(bastante logico) puedes evitarte la relacion productos-zonas ya que está
implicita en proveedor-zonas

asi te quedaria
Proveedores--[ProvZon]--zonas
|
[ProvProd]
|
productos

y una forma mas "logica" de trabajar al no tener que especificar la
relacion entre productos y zonas (que puede llegar a ser muy tediosa y
con muchos registros) , de producto a zona o zona a producto el paso con
inners lo haces rapido y en las tablas relacionadas el numero de
elementos no es tan elevado ya
(Proveedores*mediadeproveedorsporzona)+(proveedores*mediaproductosporproveedor)

eso va sobretodo encarado al manejo final de la aplicacion por los
usuarios, una vez creado todo si aparece un nuevo producto D basta con
especificarle el (o los) proveedor para saber en que zonas estara

pero claro te limita el tema de flexibilidad ya que no puedes tener
proveedores con productos para unas zonas y otros productos en otras, no
se si será critico o no en tu app


"Manuel Vera" escribió en el mensaje
news:

Gracias Mauricio por tu respuesta.
Sin embargo, no me sirve tu propuesta debido a que la regla del negocio
me indica que esas relaciones son N : M , es decir, muchos a muchos.

Ya por lo menos descarte la tabla de relación única debido a la cantidad
de registros que contiene.
Pero estoy interesado en conocer que experiencias tienen los colegas al
haber afrontado este tema.

Saludos
MV

"Mauricio Morales F. (Hero)" escribió en el mensaje
news:

Manuel,

Lo que diseñaria yo seria de la siguiente manera...

PROVEEDOR
PRODUCTO
ZONA

Luego haria una relacion de la siguiente manera

PROVEEDOR-PRODUCTO de 1 a MUCHOS
PRODUCTO-ZONA de 1 a MUCHOS.

saludos


<Information>
<Name>Mauricio Morales F</Name>
<Nick>Hero</Nick>
</Information>

"Manuel Vera" escribió en el mensaje
news:

Hola

Tengo 3 tablas principales:

PROVEEDORES
PRODUCTOS
ZONAS

Todas se relacionan entre sí con cardinalidad N><M

Es decir, 1 PROVEEDOR despacha muchos PRODUCTOS
A su vez, 1 PRODUCTO puede ser despachado por varios PROVEEDORES
(esto me crea la tabla PROV_PROD)

Es decir, en 1 ZONA se despachan muchos PRODUCTOS
A su vez, 1 PRODUCTO puede ser despachado en varias ZONAS
(esto me crea la tabla ZONA_PROD)

Es decir, 1 ZONA está cubierta por varios PROVEEDORES
A su vez, 1 PROVEEDOR puede despachar a varias ZONAS
(esto me crea la tabla ZONA_PROV)

En cada una de estas 3 tablas nuevas de relación únicamente existen
los
campos clave primaria de las tablas que las originan. No existe ningún
otro
atributo.

Finalmente, se crea entre todas ellas una relación circular:

PROVEEDOR-PRODUCTO
| |
| |
| |
ZONA-|

Las preguntas:
¿puedo crear una nueva relación única de las 3 tablas principales y
eliminar
las otras 3 tablas de relación que hay entre ellas?
¿esto me trae algún beneficio en cuanto a espacio en disco junto con
eficiencia del motor de datos?
¿Alguna sugerencia con el diseño?

La nueva tabla sería algo como:

PROVEEDOR-|
|
|
|
PRODUCTO-(NUEVA RELACION)
{IdProv , IdProd , IdZona}
|
|
|
ZONA-|

Gracias
Manuel