Ayuda con diseño de tablas

Bueno, sobre la cantidad de registros en la tabla de relacion triple (zona x
producto x proveedor) yo hice un select para tener una idea de cuantos
registros estarían involucrados. No se si es correcto, pero lo que hice fue:

select ZxP.CodZona , ZxP.CodProduct , PxZ.CodProvedr
from ( ZonaXProduct as ZxP inner join ProvedrXZona as PxZ on ZxP.CodZona =
PxZ.CodZona )
inner join ProvedrXProduct as PxP on PxZ.CodProvedr = PxP.CodProvedr

La intencion de ese SELECT es traer todos los proveedores, productos y zonas
relacionados para armar el contenido de la tabla de relación triple. Esto lo
hice en el servidor de desarrollo y me trajo luego de 16 minutos de
ejecución, un total incompleto de màs de 700.000 registros, y en eso momento
decidí detener la ejecución del comando.

En las tablas de relacion actual tengo esta cantidad de registros:
ZonaXProduct = 10861
ProvedrXProduct = 4307
ProvedrXZona = 251

Imagino que la tabla unica esta representada por:
10861 * 4307 * 251 = 11.741.360.077

Seguiré partiendome el coco en base a lo que me has indicado a ver que
solución puedo encontrar a todo este embrollo.

Gracias
Manuel


"Dani Castillo" escribió en el mensaje
news:

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

Algo no me cuadra :-S no pueden salir tantas :-S

quiero decir, la informacion actual es redundante, deberian salirnos muchas
menos posibilidades

si puedes prueba algo asi:

una consulta sencilla, proveedores->provXzona->productos
eso te dara el numero de productos tratandolos como distintos si vienen de
distinto proveedor
(es decir, para nuestros efectos el producto A es distinto si viene del
proveedor X o el Y)

eso lo cruzamos luego con la zona pero vinculando con el id_producto...
quiero decir, los inner sin pasar por la zona, algo como
select ZxP.CodZona , ZxP.CodProduct , PxZ.CodProvedr
from (ProvedrXZona as PxZ left join ProvedrXProducto as PXP on
PxZ.CodProvedr=PXP.CodProvedr) left join ZonaXProduct as ZxP on
ZxP.CodProducto = PxP.CodProducto )

lo que comento es que el maximo deberia ser:
ProvedrXProduct = 4307 => es decir, unas 4000 variantes de productos
ProvedrXZona = 251 => distribuidas sobre un maximo de 251 zonas

el tope hipotetico de esa tabla serian el numero de zonas por el numero de
proveedores por el numero de productos (suponiendo que todos venden de todo
en todas partes) parte de ese dato como primera hipotesis para descartar
posibles fallos en las consultas siguientes, cualquier valor que supere eso
estara equivocado (hablo de numero de registros en las tablas principales,
no en las relaciones) ,

visto de otro modo: haz alguna aproximacion de los datos reales con terminos
medios, algo como
numeroproveedor*mediazonasporproveedor*mediaproductosporproveedor, las
medias las puedes sacar de:
4307/numeroproveedores=mediaproductosporproveedor
251/numeroproveedores=mediazonasporproveedor

por lo tanto las relaciones son (de nuevo)
relaciones=numeroproveedores*(4307/numeroproveedores)*(251/numeroproveedores)C07x251
, son mas de 1 millon :-S pero igual ya es algo mas tratable (es un tope
maximo, suponiendo que cada proveedor distribuye todos sus productos en
todas sus zonas, lo cual lamentablemente sera habitual )

mmm no se, crei que creceria menos el asunto con la tabla asi, pero me temo
que si van a querer marcar un precio por producto , zona y proveedor el
resultado va a ser precisamente una tabla de ese calibre - el tope
hipotetico sera el numero de productos*numerozonas*numeroproveedores, no las
relaciones sino las tablas originales, aun asi es alto )

la unica manera que creo que podria evitarse es si el precio de envio es
fijo por zona y proveedor (es decir, no depende del producto, solo de quien
y donde) en ese caso dejaria las relaciones como ya las tienes y meteria el
campo precio en la tabla ProvedrXZona)






"Manuel Vera" escribió en el mensaje
news:

Bueno, sobre la cantidad de registros en la tabla de relacion triple (zona
x producto x proveedor) yo hice un select para tener una idea de cuantos
registros estarían involucrados. No se si es correcto, pero lo que hice
fue:

select ZxP.CodZona , ZxP.CodProduct , PxZ.CodProvedr
from ( ZonaXProduct as ZxP inner join ProvedrXZona as PxZ on ZxP.CodZona =
PxZ.CodZona )
inner join ProvedrXProduct as PxP on PxZ.CodProvedr = PxP.CodProvedr

La intencion de ese SELECT es traer todos los proveedores, productos y
zonas relacionados para armar el contenido de la tabla de relación triple.
Esto lo hice en el servidor de desarrollo y me trajo luego de 16 minutos
de ejecución, un total incompleto de màs de 700.000 registros, y en eso
momento decidí detener la ejecución del comando.

En las tablas de relacion actual tengo esta cantidad de registros:
ZonaXProduct = 10861
ProvedrXProduct = 4307
ProvedrXZona = 251

Imagino que la tabla unica esta representada por:
10861 * 4307 * 251 = 11.741.360.077

Seguiré partiendome el coco en base a lo que me has indicado a ver que
solución puedo encontrar a todo este embrollo.

Gracias
Manuel


"Dani Castillo" escribió en el mensaje
news:

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