Select de de tres tablas.

[satjaen]

Buenos dias, quiero hacer un select de tres tablas en las cuales dos de ellas tienen una clave (FK) llamada NUM_USUARIO, que son usuarios y dir_usuarios, pero la tercera tabla llamada avisos_wed no tiene ese clave. Podría sacar los demas datos de la tabla que tambien contienen campos como nombre,apellidos, etc. de avisos_wed?

Pongo el select que actualmente tengo con dos tablas:

Código MySQL:

SELECT U.NUM_USUARIO,U.telefono,U.nombre,U.apellidos,D.poblacion,A.telefono 
FROM usuarios U,dir_usuarios D 
WHERE  U.NUM_USUARIO=D.NUM_USUARIO AND U.telefono='$vte'";
 

Gracias y un saludo

[Heimish2000]

Pon los creates de las tres tablas.

[satjaen]

Iniciado por Heimish2000

Pon los creates de las tres tablas.

Buenos dias, te refieres a la estructura de cada tabla?

[gnzsoloyo]

pero la tercera tabla llamada avisos_wed no tiene ese clave.

Si la tercera tabla no tiene una FK que provenga de alguna de las otras dos tablas, no puedes hacer un JOIN. Ni tendría sentido hacerlo porque eso implicaría que ningún registro de "avisos_wed" está vinculado con ninguno de los de las otras.
Suena a que ese conjunto no está debidamente relacionado.

¿Cómo se relaciona la tercera tabla?

[satjaen]

Iniciado por gnzsoloyo

Si la tercera tabla no tiene una FK que provenga de alguna de las otras dos tablas, no puedes hacer un JOIN. Ni tendría sentido hacerlo porque eso implicaría que ningún registro de "avisos_wed" está vinculado con ninguno de los de las otras.
Suena a que ese conjunto no está debidamente relacionado.

¿Cómo se relaciona la tercera tabla?

Hola, entre las tres tablas las relaciono con el dato del nº de teléfono.

[satjaen]

Pongo las estructuras:

usuarios:

Código MySQL:

CREATE TABLE `wedserver2012`.`usuarios` (
`NUM_USUARIO` int( 11 ) NOT NULL AUTO_INCREMENT ,
`NOMBRE` char( 45 ) DEFAULT NULL ,
`APELLIDOS` char( 100 ) DEFAULT NULL ,
`NIF` varchar( 20 ) DEFAULT NULL ,
`TELEFONO` char( 15 ) DEFAULT NULL ,
`TELEFONO2` char( 15 ) DEFAULT NULL ,
`TELEFONO3` char( 15 ) DEFAULT NULL ,
PRIMARY KEY ( `NUM_USUARIO` ) ,
UNIQUE KEY `NUM_USUARIO` ( `NUM_USUARIO` ) ,
KEY `IUSUARIOSAPELLIDOS` ( `APELLIDOS` ) ,
KEY `IUSUARIOSINDICE` ( `NUM_USUARIO` ) ,
KEY `IUSUARIOSNOMBRE` ( `NOMBRE` ) ,
KEY `IUSUARIOSTELEFONO1` ( `TELEFONO` ) ,
KEY `IUSUARIOSTELEFONO3` ( `TELEFONO3` ) ,
KEY `IUSUARIOSTELEFONO2` ( `TELEFONO2` ) ,
KEY `IUSUARIOUSUARIOS` ( `NUM_USUARIO` )
) ENGINE = InnoDB DEFAULT CHARSET = latin1;
 

dir_usuarios:

Código MySQL:

CREATE TABLE `wedserver2012`.`dir_usuarios` (
`INDICE` int( 11 ) NOT NULL AUTO_INCREMENT ,
`NUM_USUARIO` int( 11 ) DEFAULT NULL ,
`NUM_DIR` smallint( 6 ) DEFAULT NULL ,
`CALLE` char( 30 ) DEFAULT NULL ,
`NUMERO` char( 10 ) DEFAULT NULL ,
`EDIFICIO` char( 20 ) DEFAULT NULL ,
`PUERTA` char( 10 ) DEFAULT NULL ,
`PISO` char( 5 ) DEFAULT NULL ,
`LETRA` char( 5 ) DEFAULT NULL ,
`POBLACION` varchar( 30 ) DEFAULT NULL ,
`PROVINCIA` varchar( 25 ) DEFAULT NULL ,
`COD_POSTAL` varchar( 12 ) DEFAULT NULL ,
`OBS_DIRECCION` char( 80 ) DEFAULT NULL ,
`PAIS` varchar( 20 ) DEFAULT NULL ,
`CODIGO_SAT` char( 15 ) DEFAULT NULL ,
`EMAIL` char( 100 ) DEFAULT NULL ,
PRIMARY KEY ( `INDICE` ) ,
UNIQUE KEY `INDICE` ( `INDICE` ) ,
KEY `IDIRUSUARIOSCALLE` ( `CALLE` ) ,
KEY `IDIRNUMUSUARIOSPOBLACION` ( `POBLACION` ) ,
KEY `IDIRUSUARIOSUINDICE` ( `INDICE` )
) ENGINE = InnoDB DEFAULT CHARSET = latin1;
 

avisos_wed:

Código MySQL:

CREATE  TABLE  `wedserver2012`.`avisos_wed` (  `id_aviso` int( 11  )  NOT  NULL  AUTO_INCREMENT ,
 `id_factura` varchar( 100  )  NOT  NULL ,
 `realizacion` date NOT  NULL ,
 `recepcion` date NOT  NULL DEFAULT  '0000-00-00',
 `emision` date NOT  NULL ,
 `NOMBRE` varchar( 50  )  NOT  NULL ,
 `APELLIDOS` varchar( 100  )  NOT  NULL ,
 `NIF` varchar( 10  )  NOT  NULL ,
 `TELEFONO2` varchar( 50  )  NOT  NULL ,
 `calle` varchar( 200  )  NOT  NULL ,
 `numero` varchar( 10  )  NOT  NULL ,
 `edificio` varchar( 10  )  NOT  NULL ,
 `letra` varchar( 10  )  NOT  NULL ,
 `piso` varchar( 10  )  NOT  NULL ,
 `puerta` varchar( 10  )  NOT  NULL ,
 `POBLACION` varchar( 100  )  DEFAULT NULL ,
 `provincia` varchar( 100  )  NOT  NULL ,
 `email` varchar( 100  )  NOT  NULL ,
 `aparatos` varchar( 50  )  NOT  NULL ,
 `marcas` varchar( 50  )  NOT  NULL ,
 `modelo` varchar( 50  )  NOT  NULL ,
 `codigo` varchar( 100  )  NOT  NULL ,
 `serie` varchar( 100  )  NOT  NULL ,
 `compra` date NOT  NULL ,
 `tecnico` varchar( 10  )  NOT  NULL ,
 `tipo` varchar( 100  )  NOT  NULL ,
 `facturacion` varchar( 100  )  NOT  NULL ,
 `situacion` varchar( 40  )  NOT  NULL ,
 `sintoma` varchar( 200  )  NOT  NULL ,
 `observaciones` varchar( 400  )  NOT  NULL ,
 `privadas` varchar( 400  )  NOT  NULL ,
 `TELEFONO` int( 100  )  DEFAULT NULL ,
 `distribuidor` varchar( 100  )  NOT  NULL ,
 `TELEFONO3` varchar( 15  )  DEFAULT NULL ,
 PRIMARY  KEY (  `id_aviso`  )  ) ENGINE  = InnoDB  DEFAULT CHARSET  = latin1;
 

Perdon, me he equivocado la tabla dir_usuarios no tiene el campo TELEFONO.
Podria relacionar la tabla usuarios y avisos_wed ya que tienen el campo TELEFONO verdad?

[gnzsoloyo]

Empecemos por el principio: Parece evidente que no terminas de entender qué es una FK.
Dos tablas se relacionan no por un campo cualquiera (y usar un teléfono es una pésima elección), sino por su FK, y una FK es un campo o conjunto de campos cuyo valor referencia a la PK de otra tabla.
Para ser preciso, tu no tienes definida ninguna FK en tus tablas, porque "num_usuario" no está declarada como tal en la tabla dir_usuarios. Incluso más: Ni siquiera está definida como Key en esa misma tabla, con lo que toda consistencia de datos la debes estar manteniendo programáticamente, con todos los errores que eso puede causar luego.

Creo que deberíamos dar un paso atrás y empezar a ver de nuevo algunos principios que parecen no estar correctamente implementados en esa base.
Ten en cuenta que si la base no está bien diseñada, o al menos correctamente implementada, todo ello te traerá problemas al realizar consultas, que no te dará las respuestas correctas precisamente por una consistencia que tu base no es capaz de asegurar.

PD: Por favor, usa la etiqueta de Highlight correcta para el SQL. Ya te aclaré que PHP no es SQL.

[satjaen]

Iniciado por gnzsoloyo

Para ser preciso, tu no tienes definida ninguna FK en tus tablas, porque "num_usuario" no está declarada como tal en la tabla dir_usuarios. Incluso más: Ni siquiera está definida como Key en esa misma tabla, con lo que toda consistencia de datos la debes estar manteniendo programáticamente, con todos los errores que eso puede causar luego.
PD: Por favor, usa la etiqueta de Highlight correcta para el SQL. Ya te aclaré que PHP no es SQL.

gnzsoloyo, num_usuario no la tengo como primaria porque tengo registros duplicados. Es decir el mismo nº de usuario puede tener varias direcciones.
PD: ya vi la pestaña MySQL. Gracias

[gnzsoloyo]

num_usuario no la tengo como primaria porque tengo registros duplicados. Es decir el mismo nº de usuario puede tener varias direcciones.

Bueno, al decirme eso me estás confirmando que tu base está mal planteada, pero además que no tienes claro lo que es una FK.
Yo no estoy diciendo que num_usuario pueda ser PK de dir_usuario, sino que num_usuario debe ser FK (foreign key) de dir_usuario, que es algo completamente diferente.
Al definir a num_usuario como FK en dir_usuario lo que sucede es que se mantiene una integridad completa de datos entre un usuario determinado y cada una de sus direcciones, que pueden ser N direcciones, pero en el contexto de tu caso puedes perfectamente poner una dirección con un num_usuario inexistente, porque la base no puede asegurar por si misma la integridad y consistencia de ese dato.
Ahora bien, en el caso de al tercera tabla, si avisos_wed se debe corresponder con un usuario y además con una dirección dada, entonces requiere que ambas PK de cada tabla estén en ella como FK, lo que determinaría completamente la relación y el JOIN sería posible de realizar.
Si la dirección no es determinante, entonces sólo debería ir el num_usuario, pero aún así debería ser FK.

¿Vas entendiendo la lógica del asunto?

Si no defines jamás podrías asegurar la consistencia de los datos, y por ende terminarías teniendo datos-basura.

[satjaen]

Iniciado por gnzsoloyo

Bueno, al decirme eso me estás confirmando que tu base está mal planteada, pero además que no tienes claro lo que es una FK.
Yo no estoy diciendo que num_usuario pueda ser PK de dir_usuario, sino que num_usuario debe ser FK (foreign key) de dir_usuario, que es algo completamente diferente.
Al definir a num_usuario como FK en dir_usuario lo que sucede es que se mantiene una integridad completa de datos entre un usuario determinado y cada una de sus direcciones, que pueden ser N direcciones, pero en el contexto de tu caso puedes perfectamente poner una dirección con un num_usuario inexistente, porque la base no puede asegurar por si misma la integridad y consistencia de ese dato.
Ahora bien, en el caso de al tercera tabla, si avisos_wed se debe corresponder con un usuario y además con una dirección dada, entonces requiere que ambas PK de cada tabla estén en ella como FK, lo que determinaría completamente la relación y el JOIN sería posible de realizar.
Si la dirección no es determinante, entonces sólo debería ir el num_usuario, pero aún así debería ser FK.

¿Vas entendiendo la lógica del asunto?

Si no defines jamás podrías asegurar la consistencia de los datos, y por ende terminarías teniendo datos-basura.

OK, entonces me he confundido. Pero donde esta en Myadmin FK?, yo pensaba que era un simbolo de una llave dorada.
Porque en la tabla usuarios esta bien?

Código MySQL:

PRIMARY KEY ( `NUM_USUARIO` ) ,
 

[gnzsoloyo]

Básicamente está bien, aunque hay tres consideraciones:
- Por un lado, si el NIF es obligatorio (no sé lo que es, pero supongo que se parece a nuestro CUIT), eso podría ser suficiente para establecer una PK, con lo que hacerla numérica y autoincremental puede terminar siendo redundante. En todo caso es una decisión de diseño. Depende de lo que quieras hacer.
- Si un usuario puede tener 0 a N teléfonos, los teléfonos no van en la tabla. Poner una cantidad fija puede ser demasiado o muy poco, dependiendo del caso, y desperdiciar espacio jamás es buena idea, aunque te sobre. Además, si pones un campo por teléfono también estás complicando las consultas, porque el teléfono lo deberás buscar en cada uno de los campos, mientras que ponerlos en otra tabla relacionada por el num_usuario te permitirá consultar siempre el mismo, y la consulta será más simple.
- Son demasiados índices. Los índices siempre tienen impacto en la performance con los INSERT/UPDATE, por lo que si se esperan muchas entradas, tantos indices conspiran en contra. Es preferible la cantidad de indices justa y con buena selectividad.

Respecto a lo de la tabla dir_usuarios, en realidad tiene ciertos defectos.
Una tabla que contiene direcciones no conviene que tenga campos VARCHAR para poner manualmente los nombres de ciudades, provincias, países, y cosas así. Eso es preferible manejarlos en tablas independientes, y que sean relacionados a la tabla de direcciones por su PK. Es decir: Lo que van son campos numéricos, que sean las FK de las Localidades, Paises, Provincias o Departamentos (o como se llamen las subdivisiones provinciales).
Así es como se hace usualmente.

Hay al menos un par de razones para hacerlo así:

1) No necesitas desperdiciar espacio para almacenar N veces la misma localidad, departamento, provincia y país.

2) Evitas que el usuario meta la pata y de pongan Cba., Cord., Cordova, Córdova o Córdoba como ciudad, lo que terminaría interpretándose como cinco ciudades distintas, cuando en realidad es una sola.

Nunca te olvides que al usuario hay que dejarle el menor dominio posible sobre cosas que son estandarizadas, ya que la mayor fuente de errores es... la interfase silla-teclado, como decía un amigo mío (el usuario).

En definitiva, es mejor que separes esos datos en otras tablas (relacionadas entre sí a su vez para que cada ciudad corresponda con su provincia y cada provincia con su país), y no dejarlos así.

Finalmente, la tercera tabla tiene un defecto primario: Si el gestionante es un usuario, y el usuario tiene siempre al menos una dirección, a menos que la transacción deba ser entregada en otra parte no declarada, no tiene sentido ni utilidad que los datos de dirección estén allí. Son redundantes, bastaría con el id del usuario y de la direccion que usará.
Y aún así, si la dirección de entrega es diferente a las declaradas, eso sería un caso opcional y no obligatorio, por tanto esos datos deberían estar en una tabla específica relacionada con la tercera tabla, donde sólo se consultarían si un campo dir_usuario_id (la dirección destino a usar) fuese NULL.
Es decir: Lo que tendría más sentido es que el usuario que hace la gestión declare en cuál dirección registrada será entregado lo que sea, y en caso de definir otra dirección no declarada, que ese conjunto de datos sea o una dirección declarada nueva, o una dirección de destino de la transacción. En el segundo caso esos datos deberían ir en una tabla separada y relacionados con el ID de la tercera tabla.

Es posible que esto te resulte algo pesado, y un poco engorroso por la falta de experiencia en el diseño de bases de datos, pero te puedo asegurar con conocimiento de causa, que normalizar las tablas mas o menos como te describo hará que a la larga no tengas tantos problemas al construir las consultas, y posiblemente no te veas obligado a modificar la base, cuando esta ya esté productiva.
Modificar bases en trabajo es la pesadilla de los DBA.

[satjaen]

Ok, gnzsoloyo muchas gracias por explicarme tantas cosas. Pero crees que podremos sacar datos de la tabla avisos_wed con la consulta:

Código MySQL:

SELECT U.NUM_USUARIO,U.telefono,U.nombre,U.apellidos,D.poblacion 
FROM usuarios U,dir_usuarios D 
WHERE  U.NUM_USUARIO=D.NUM_USUARIO AND U.telefono='$vte';
 

O tendremos que hacer un segunda consulta despues de esta para la tabla avisos_wed?

Gracias de verdad por tú tiempo.

[gnzsoloyo]

Intentalo, si quieres. En el estado actual de esa estructura de tablas no te puedo garantizar que la consulta funcione bien, porque es imposible saber si hay inconsistencias previas.
Personalmente, ni me molestaría en seguir avanzando con las consultas, sin haber normalizado esas tablas. Para mí, es una pérdida de tiempo y esfuerzo.
Pero eres tu quien tiene que tomar esa decisión, no yo.

Lo que si te sugiero es que uses correctamente los JOIN, y evites usar las relaciones en el WHERE, porque el parser de MySQL no lo puede optimizar.
Lo que me preguntas es algo como:

Código MySQL:

SELECT U.NUM_USUARIO,U.telefono,U.nombre,U.apellidos,D.poblacion
FROM usuarios U 
    INNER JOIN dir_usuarios DON U.NUM_USUARIO = D.NUM_USUARIO 
    INNER JOIN avisos_wed A DON U.telefono = A.telefono 
WHERE U.telefono='$vte';
 

PD: No sólo tienes que etiquetar correctamente el Highlight. Tienes que quitar TODO lo que sea PHP.

[satjaen]

Iniciado por gnzsoloyo

Intentalo, si quieres. En el estado actual de esa estructura de tablas no te puedo garantizar que la consulta funcione bien, porque es imposible saber si hay inconsistencias previas.
Personalmente, ni me molestaría en seguir avanzando con las consultas, sin haber normalizado esas tablas. Para mí, es una pérdida de tiempo y esfuerzo.
Pero eres tu quien tiene que tomar esa decisión, no yo.

Lo que si te sugiero es que uses correctamente los JOIN, y evites usar las relaciones en el WHERE, porque el parser de MySQL no lo puede optimizar.
Lo que me preguntas es algo como:

Código MySQL:

SELECT U.NUM_USUARIO,U.telefono,U.nombre,U.apellidos,D.poblacion
FROM usuarios U 
    INNER JOIN dir_usuarios DON U.NUM_USUARIO = D.NUM_USUARIO 
    INNER JOIN avisos_wed A DON U.telefono = A.telefono 
WHERE U.telefono='$vte';
 

PD: No sólo tienes que etiquetar correctamente el Highlight. Tienes que quitar TODO lo que sea PHP.

gnzsoloyo lo he puesto así, porque creo que te ha faltado la D en dir_usuarios no?, pero de todas formas con la D puesta tampoco me encuentra resultados.
Una pregunta, que es el DON?

Código MySQL:

SELECT U.NUM_USUARIO,U.telefono,U.nombre,U.apellidos,D.poblacion,A.telefono
FROM usuarios U 
    INNER JOIN dir_usuarios D DON U.NUM_USUARIO = D.NUM_USUARIO 
    INNER JOIN avisos_wed A DON U.telefono = A.telefono 
WHERE U.telefono='$vte'
 

[gnzsoloyo]

Una pregunta, que es el DON

Un error de tipeo....
Creo que es bastante evidente, ¿no?

Código MySQL:

SELECT U.NUM_USUARIO,U.telefono,U.nombre,U.apellidos,D.poblacion,A.telefono
FROM usuarios U
INNER JOIN dir_usuarios D ON U.NUM_USUARIO = D.NUM_USUARIO
INNER JOIN avisos_wed A ON U.telefono = A.telefono
WHERE U.telefono='$vte'
 

PD: Si no te devuelve nada, eso sólo significa una cosa: Tienes inconsistencia de datos.

[satjaen]

Iniciado por gnzsoloyo

Un error de tipeo....
Creo que es bastante evidente, ¿no?

Código MySQL:

SELECT U.NUM_USUARIO,U.telefono,U.nombre,U.apellidos,D.poblacion,A.telefono
FROM usuarios U
INNER JOIN dir_usuarios D ON U.NUM_USUARIO = D.NUM_USUARIO
INNER JOIN avisos_wed A ON U.telefono = A.telefono
WHERE U.telefono='$vte'
 

PD: Si no te devuelve nada, eso sólo significa una cosa: Tienes inconsistencia de datos.

gnzsoloyo, no me tira resultados. He pensado en hacer dos select, para si en el primer select no esta el telefono que busque en el segundo:

1º Consulta:

Código MySQL:

SELECT U.NUM_USUARIO,U.telefono,U.nombre,U.apellidos,D.poblacion
FROM usuarios U,dir_usuarios D 
WHERE  U.NUM_USUARIO=D.NUM_USUARIO AND U.telefono='$vte';
 

2º Consulta:

Código MySQL:

SELECT A.telefono FROM  avisos_wed A WHERE A.telefono='$vte';
 

Pero no sé como plantearlo.


EDITO: gnzsoloyo, voy a intentarlo en el foro de php y si no puedo ya te digo algo. Gracias

[satjaen]

gnzsoloyo, ya he podido resolverlo en php. Gracias y felices fiestas

[gnzsoloyo]

Genial. Me alegro que hayas podido.