Yo no me enrrollo, pero me has estado dando vueltas sin responder esa pregunta.
Para mi, es increíble que puedas llegar a este punto:
Código MySQL:
Ver original ciudad = '$ciudad'
Y EDAD DECLARADA ENTRE $minimo
Y $ maximo
Y no ser capaz de escribir por ti mismo algo como:
Y saltar de allí a rangos múltiples como
Francamente no comprendo cómo es que no lo ves, cuando ya lo estás escribiendo en pseudocódigo.
Además, postear las tablas es un requisito casi básico en este foro, porque hay cosas que no se perciben en lo que el forista describe, como por ejemplo, que
estás cometiendo un error gravísimo al crear esa tabla, por cuanto estás poniendo como VARCHAR un campo de
edad.
Una edad es una magnitud, y como tal sólo puede ser almacenada como
número, en este caso un INT UNSIGNED, y
jamás como texto.
Cuando almacenas la edad como texto, el numero se evalúa como texto, lo que hace que en el rango, "100" esté antes que "2"... Lo que es obviamente un error total (hay otras palabras para describirlo, pero no las pondré).
Y eso no lo puedo saber
a menos que vea qué estructura tiene la tabla, porque tu me estás hablando de un campo "edad", del que yo asumo (porque es evidente que
debe ser así) que es numérico. Y no es tal.
¿Se entiende?
También veo que estás almacenando la
fecha como VARCHAR, lo que es otro error catastrófico. Supongo porque la estas guardando como DD/MM/AAAA, lo que también está mal.
Una fecha es una columna de tipo DATE, TIMESTAMP o DATETIME, pero
jamás un VARCHAR. Cuando la pones como tal puede terminar siendo que el 31/01/1645 sea mayor (posterior) al 02/12/2578, lo que es obviamente absurdo.
Ese tipo de error es muy común en los programadores, que confunden la fecha
para mostrar en pantalla, con el formato de
almacenamiento de datos.
Son cosas totalmente distintas.
¿Se van entendiendo los problemas que se plantean en tu modelado de datos?
Si voy a hilar fino, incluso las longitudes de los campos VARCHAR son incorrectas, porque no cumplen con lo necesario para la mayoría de los casos y pueden terminar truncando datos, lo que generaría errores graves en las consultas y reportes.
La tabla debería ser mas o menos así:
Hay algunas otras consideraciones como por ejemplo:
- INT(50) es incorrecto, porque ni un BIGINT tiene esa cantidad de cifras, y
ese valor entre paréntesis no representa tampoco la el ancho de la cifra. El máximo en INT es 11, por ejemplo.
- Los países y ciudades es mejor que estén en tablas independientes, relacionadas por FK con esta, donde lo único que se pone es el ID del país y el ID de la ciudad, y no el nombre.
- "Codigo" termina siendo una PK alternativa cuando la declaras como UNIQUE. No se comprende su uso, pero si es numérico no debería ir como VARCHAR.
Puede que esto te parezca demasiado y que lo único que desees sea "la consulta", pero entiende que una base mal diseñada, sólo devolverá datos-basura (información incorrectamente procesada o errónea), porque no cumple con lo necesario para dar buenos resultados.