Que estoy haciendo mal??

[Sensorium]

Hola a todos, aqui ando con un problemita de SQL, el tema es el siguiente, debo obtener el id_orden de una tabla en donde el id_cliente puede ser el resultado de 2 diferentes tablas, pongo el codigo y la explicacion:

Código:

SELECT 
orden_trabajo.numero,
orden_trabajo.id_orden,
orden_trabajo.id_cliente 
FROM orden_trabajo, organizaciones, contactos where
organizaciones.id_organizacion=orden_trabajo.id_cliente and 
organizaciones.codigo_postal='09119'
or
contactos.id_contactos=orden_trabajo.id_cliente and 
contactos.codigo_postal='09199'
order by orden_trabajo.numero ASC

Tengo tres tablas:
ORDENES TRABAJO, ORGANIZACIONES, CONTACTOS
en las ordenes de trabajo tengo un ID_CLIENTE (que es el que quiero filtrar junto con el CP) que puede ser o un id_organizacion o un id_contactos, si pongo esa sentencia SQL me devuelve por ejemplo 45 veces la misma id_orden, que hago mal?

PD: Si lo hago con 2 tablas me devuelve los registros bien!

[Sensorium]

Alguien me da una mano, estoy trancado con esto

[jurena]

A ver si he entendido. ¿Cómo es esto: id_cliente puede ser el resultado de 2 diferentes tablas? Pon ejemplos. ¿Quieres decir que un id_cliente número 1 puede aparecer como id en las tablas organizaciones y contactos. Es decir, que puedes tener un idorganizaciones 1 y un idcontactos 1 . Si eso es así, tienes un problema, porque una de las características de las claves primarias es que sean únicas, y si tú las duplicas, cómo distingues una de otra. Podrías con un UNION ALL traértelo, pero ¿cómo distingues un 1 de organizaciones de otro de contactos.
Dinos cuál es la estructura de tus tablas, sus campos y tipos y las relaciones. Pon algún ejemplo y tal vez podamos sugerirte algo.

[Sensorium]

jaurena, gracias por contestar, te explico, el IDCLIENTE puede ser un IDCONTACTOS o un IDORGANIZACION, cuando creas una Orden de Trabajo seleccionas el cliente de una lista, en donde te aparecen Organizaciones y Contactos, solo puede seleccionar 1 y ese será el IDCLIENTE de la orden de trabajo, ahora bien cuando filtro mi búsqueda lo debo hacer por el CODIGO POSTAL del cliente selecionado, para eso es necesario Primero saber si es una Organización o un Contacto y ademas debo chequear que el Codigo Postal de este registro sea igual a 09119 (en realidad es una variable post), sen entiende? GRACIAS ESPERO TU RESPUESTA

[jurena]

Lanza esta consulta de UNION, pero antes comprueba los nombres de los campos.

Prueba con esto.
Luego ordenaremos:

(SELECT t.numero, t.id_orden, t.id_cliente, c.codigo_postal FROM orden_trabajo t INNER JOIN contactos c ON t.id_cliente = c.id_contactos WHERE c.codigo_postal='09199')
UNION ALL
(SELECT t.numero, t.id_orden; t.id_cliente, o.codigo_postal FROM orden_trabajo t INNER JOIN organizaciones o ON t.id_cliente = o.id_organizacion WHERE o.codigo_postal='09199')

[Sensorium]

jaurena eh probado tu codigo y me ha ido de maravilla!, bueno solo queda chequear que la cantidad de registros arrojados sea la correcta pero al parecer SI!!!

MUCHISIMAS GRACIAS!!

[jurena]

El único problema que veo es que un mismo id_cliente pudiera aparecer como id_organizacion e id_contactos.

[Sensorium]

Iniciado por jurena

El único problema que veo es que un mismo id_cliente pudiera aparecer como id_organizacion e id_contactos.

No , no es así, un id_cliente puede ser un id_contactos o un id_organizacion, nunca los dos a la vez, otra manera no encontré para hacerlo ya que tengo dos tablas (contactos, organizaciones) y cualquiera de los dos pueden ser clientes, cual es el problema que ves, me interesa tu opinión. jaurena Muchas Gracias

[jurena]

No soy técnico Sensorium, pero te diré mi opinión. No veo problema realmente. Lo que estabas haciendo era un join entre tres tablas que realmente tú no querías unir: el OR sólo te servía para multiplicar más: por eso te salían multiplicados los datos.
En realidad, que yo sepa, para esa estructura tenías dos opciones: adaptar una tabla para poder meter los datos de contactos y organizaciones, con un campo que las identificara: 0 para contactos y 1 para organizaciones. Sé que se pierde espacio y que tendrás usar nombres de campos que te sirvan para ambos y adaptar algunos contenidos, pero en realidad ya lo tienes hecho, pues los campos se parecen mucho por lo que veo en tus consultas. Problema: pierdes espacio de almacenamiento si contactos tiene un campo que no tenga organizaciones y viceversa, tendrás que contar con ese campo y quedará null, vacío o algún otro valor por defecto, para el otro. Ventaja: sólo una consulta, y para distinguir uno de otro sólo tienes que poner en la condición de la consulta que sea igual a 0 ó 1 el campo que sirve como identificador de contactos y organizaciones. Podrías además, usar un id numérico autoincrementable, porque imagino que ahora tu identificador será de texto, dado que si es numérico podrían darse coincidencias y te sacaría datos repetidos (era mi principal temor, aunque podrías resolverlo con un rango distinto para cada tabla, usando letras y números, etc.).
Lo otro, lo que has hecho, puede seguir funcionando, pero para cada consulta en la que quieras buscar contactos y organizaciones, tendrás que hacer una consulta de union (es decir, dos consultas en una): si no son muchas, tampoco le veo mucho problema.
Es lo que te puedo decir, porque me falta saber si esas tablas se usan en otras relaciones con otras tablas y tienes muchos datos de organizaciones incluidos en campos sin correspondencia en contactos y viceversa. Tienes que ver lo que más te conviene, y yo sólo veo la punta del iceberg. Pero eso es lo que opino de lo que veo.
En resumen, que si contactos y organizaciones son entidades distintas con atributos propios, déjalo como lo tienes; en caso contrario, haz de ellas una entidad de la que uno de sus atributos sea ser contactos u organización. ¿Cómo lo sabrás? Si contactos y organizaciones hacen lo mismo, reciben órdenes de trabajo, etc., siempre, podrás hacer de ellas una única entidad.

[Sensorium]

Bueno jurena, la verdad MUY agradecido por tu respuesta, en realidad no es mala idea lo de unir las entidades , quizá utilizando los campos de manera diferente, por ejemplo el campo apellidos en contactos seria razón social en organizaciones y etc.., pero no es mala idea le plantearé al cliente este posible cambio y MIL GRACIAS jurena .

[jurena]

Sensorium, estudia bien la situación, las acciones de las entidades, todas las consultas que necesitarás para obtener los resultados que obtienes ahora y que previsiblemente necesitarás obtener en el futuro, etc., y los problemas que te podrías encontrar con una y con otra estructura en cada caso. No cambies nada sin estudiar las posibilidades.

Un saludo