se duplican los resultados exponencialmente con inner join

[carlos b]

buenas tardes mi saludos y respeto ante todo. el problema es con inner join, explico, tengo 3 y mas tablas con un cod en comun (la ubicacion), ahora bien, cuando enlazo T1, T2, T3, Tn... con relacion al cod (ubicación), se multiplican los registros resultantes, cuando hay un solo registro, no hay problema. Pero cuando hay mas de uno, se multiplican exponencialmente los resultados e probado con "distinc" pero es igual. la setencia utilizada es ej "select t1.nombre,t2.marca,t3.sn from t1 inner join t2 on t1.codubi=t2.codubi inner join t3 on t2.codubi=t3.codubi where t1.codubi=value". los resultados se expresa en x^2 y al agregar "group by" al final de la exprecion para intentar agruparlos, me da un error.

Gracias de antemano

[Luis Mata]

Que error?

--
 
 
 

[Pablo Daniel Lissa]

Hola:

Serían necesarias algunas especificaciones más:
1- "Cuando hay un solo registro, no hay problema". ¿A qué te referís exactamente? ¿Un registro en cada tabla?

2- ¿codubi debe ser única en esas tablas? Por ejemplo, si el valor se pudiera repetir se daría algo como lo siguiente:
Escenario
T1: 1 registro con codubi = cod1.
T2: 3 registros con codubi = cod1
T3: 4 registros con codubi = cod1

Una consulta SELECT con INNER JOIN de las 3 tablas arrojaría 1 x 3 x 4 = 12 registros de resultado.

Espero que te sirva. Saludos.
----------------------------------------------------------------------------------------------------

[carlos bermudez]

Muchisimas gracias Sr. Pablo por atender mi inquietud. Me explico mejor, tengo el mismo numero de registro en todas las tablas, diferenciada solo por el CODUBI, si tengo 4 registros en T1 con su respectivo codubi, tendran en las demas tablas el mismo numero de registros con el mismo codubi, pero obviamente con otros datos segun sea la Tabla. Ahora bien, al al decir que "Cuando hay un solo registro, no hay problema", es que al solicitar (con el codubi) y solo existe un solo registro en todas las tablas aparece bien, como deberia ser, peeeero al ser mas de una coincidencia se multiplican los resultados... adjunto dos imagenes, donde "un_registro" es solo una coincidencia en 3 tablas, y donde dice "mas de uno" solo existen realmente 3 registros que coninciden en 3 tablas, pero el resultado es 27...
 

--
 
 
 

[Pablo Daniel Lissa]

Carlos. Buenas tardes.

Me va quedando mucho más claro el escenario del problema. Me voy formando algunas hipótesis, pero todavía tengo que preguntar unas cosas más:
1- Los campos que no fueron especificados en el primer post (so, serial_teclado, serial_raton) ¿se encuentran en las mismas tablas o en otras? (Para descartar problemas con otras asociaciones).
2- Las tablas ¿son DBF? Y de ser así, ¿de qué tipo de dato es CODUBI?

En el caso de que las tablas sean DBF y CODUBI fuese caracter, podría llegar a darse un problema de exactitud del operador =, y habría que reemplazarlo por ==.

Saludos.
--------------------------------------------------------------------------------------------------------------------------------

[carlos bermudez]

OK amigo  Pablo, son 3 tablas (por ahora), donde en una se especifica todos los datos de CPU, otra de los teclados y una ultima de los ratones... son parte de una DB donde son parte de otras tablas (DBF) que especifican otros componentes, el CODUBI es un campo numerico que es la ubicacion fisica de los equipos, por ende cada cpu cuenta con sus perifericos... ya utilice ==, DISTINC, y no veo problema en la sentencia SQL
SELECT  t_pc.marca,t_pc.modelo,t_pc.sn,t_pc.so,t_teclado.sn as serial_teclado,t_raton.sn as serial_raton FROM t_pc ;
                inner JOIN t_teclado ON t_pc.codubi=t_tec.codubi ;
                INNER JOIN t_ratton ON t_teclado.codubi=t_rat.codubi ;
                WHERE t_raton.codubi=m.ubi

--
 
 
 

[Pablo Daniel Lissa]

¿Es correcto si digo que las tabla originales contienen lo siguiente (aproximadamente; omito algunos campos)?

t_PC
marca     modelo     codubi
HP         DC5700     1
IBM        8149KSA   2
VIT         2600          3

t_teclado
sn            codubi
BC33...     1
KB08...     2
ZCE8...     3

t_raton
sn            codubi
MS08...     1
2338...      2
1498...      3


Si es así, amigo mío, estamos al horno. Descubriste un SELECT mágico. Jajaja.

Saludos.
----------------------------------------------------------------------------------------------------

[carlos bermudez]

eso es correcto.

--
 
 
 

[carlos bermudez]

para mayor precision seria algo asi:

t_PC
marca          modelo     codubi
HP              DC5700        1
IBM             8149KSA      2
VIT             2600             3

LENOVO    XL235           1
DELL         RP235           1
DELL        MPO...           2

t_teclado
sn                             codubi
BC33...                          1
KB08...                          2
ZCE8...                         3

XC58..                           1
W45...                          1
Q56...                          2

t_raton
sn                              codubi
MS08...                        1
2338...                         2
1498...                         3

898E...                        1
369...                          1
7ER...                         2

[Pablo Daniel Lissa]

Creo que llegamos al punto. No hay ningún error en la consulta, sino en el diseño de los datos. Por ejemplo, para CODUBI = 1
1- La relación entre t_PC y t_teclado arroja 9 registros de resultado (por coincidencia de los CODUBI):
    HP con BC33..., con XC58.. y con W45...     (3 registros)
    LENOVO con BC33..., con XC58.. y con W45...     (3 registros)
    DELL con BC33..., con XC58.. y con W45...     (3 registros)

2- La relación entre el resultado parcial del paso 1 y la tabla t_raton arrojaría 9 x 3 = 27 registros de resultado (9 por los registros del paso 1, y 3 por los registros de la tabla t_raton tal que CODUBI = 1).

A esto me refería cuando en post anteriores pregunté si CODUBI debía ser única en la tabla. Evidentemente, no, porque varios registros de una misma tabla tienen un mismo CODUBI. Creo que se necesitaría algún campo más que relacione 1 registro de t_PC con 1 (y solo 1) registro de t_teclado.

Espero que puedas solucionarlo. Respecto al uso de JOIN, dejo un link a una imagen que ya han posteado antes en este foro y que es muy útil:
http://www.resuelvetusproblemas.com/wp-content/uploads/2012/03/sql-joins-ejemplos.png

Saludos.
-------------------------------------------------------------------------------------------------------------------------------------

[mpulla]

Hola Carlos.

Al igual que Pablo, pienso que es un error de diseño de db.

Toma a un PC como una unidad operativa que tiene sus componentes, entonces una unidad operativa puede estar físicamente en una sola ubicación.

Tendrías una diseño más o menos así

Tabla Ubicacion

CodUbi, Descripcion

1, Ventas

2, Bodega

3, Sistemas

Tabla t_pc.

PCId, Descripcion, Marca, Modelo, Serie, codubi

1       PC1,   HP, XXX, XXX, XXX, 1

2       PC2,   HP, YYY, YYY, YYY, 1

Tabla t_ComponenteTipo

CmpTipoId, Descripcion

1, Teclado

2, Monitor

3, Raton

Tabla t_PC_Componente

PCId, CmpTipoId, Serie, ...

1, 1, s2xwe7

1, 2, 1xows2

1, 3, 3rw53so

2, 1, w2we3l

2, 2, w291jwss

2, 3, 12e3kdkc

Select u.CodUbi, u.Descripcion As Ubicacion,  p.PCId, p.Descripcion UOPerativa, p.Marca, p.Modelo, p.Serie,;

t.Descripcion As Componente, c.Serie As CmpSerie;

From Ubicacion As u ;

Inner Join t_pc As p On u.CodUbi = p.CodUbi;

Inner Join t_PC_Componente c On p.PCId = c.PCId;

Inner Join t_ComponenteTipo t On c.CmpTipoId = t.CmpTipoId

Where u.CodUbi = m.ubi

Saludos.

Mauricio.

[Víctor Hugo Espínola Domínguez]

Hola Mauricio

En Paraguay casi todos los negocios que venden artículos informáticos manejan las ofertas despiezadas, por así decirlo. El cliente elige la CPU con determinada configuración, el gabinete, el teclado, el mouse, el monitor, etc...

Por lo tanto no se puede armar un Kit estático, porque sería irreal. Pero por otro lado reconozco que su diseño de datos se puede mejorar.

En todo caso lo que puede hacer para obtener el informe en el formato que el pretende es armar un array o un cursor leyendo secuencialmente cada una de las tablas e ir grabando los datos en su ubicación correspondiente.

Es mi humilde opinión, a ver que dicen los demás compañeros.

Saludos.

Víctor.

--
 
 
 

[mpulla]

Hola Víctor 

Por la data que expuso Carlos me incline a pensar que la problemática se orientaba a activos fijos donde una unidad operativa ya esta dada.

En negocio de ventas de computadores, el modelo te sirve para generar Ordenes de trabajo cuando el cliente configuro el PC a su gusto, es decir armo su kit estático.

<<En todo caso lo que puede hacer para obtener el informe en el formato que el pretende es armar un array o un cursor leyendo secuencialmente cada una de las tablas e ir grabando los datos en su ubicación correspondiente.

Coincido en lo que dices.

Saludos.

Mauricio

[carlos bermudez]

Buenos Dias. Ok, gracias a todas las colaboraciones, revisare y rearmare la estructura de los datos para darle mejor viabilidad.

Gracias..
 

--