Consultar usuarios por rango de edad

[gnzsoloyo]

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:

SELECT * 
FROM base
WHERE 
    ciudad = '$ciudad' 
    AND pais = '$pais' 
    Y EDAD DECLARADA ENTRE $minimo Y $ maximo
ORDER BY id DESC;
 

Y no ser capaz de escribir por ti mismo algo como:

Código MySQL:

SELECT * 
FROM base
WHERE 
    ciudad = '$ciudad' 
    AND pais = '$pais' 
    AND edad BETWEEN $minimo AND $ maximo
ORDER BY id DESC;
 

Y saltar de allí a rangos múltiples como

Código MySQL:

SELECT * 
FROM base
WHERE 
    ciudad = '$ciudad' 
    AND pais = '$pais' 
    AND 
    (edad BETWEEN 20 AND 30
    OR
    edad  BETWEEN 40 AND 60)
ORDER BY edad, id DESC;
 

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í:

Código MySQL:

CREATE TABLE `base` (
  `id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
  `nombre` VARCHAR(100) NOT NULL,
  `edad` INT UNSIGNED NOT NULL,
  `email` VARCHAR(255) NOT NULL,
  `pais` VARCHAR(60) NOT NULL,
  `ciudad` VARCHAR(100) NOT NULL,
  `codigo` VARCHAR(15) NOT NULL,
  `fecha` DATE NOT NULL,
  `contra` VARCHAR(25) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `codigo` (`codigo`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci
 

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.