AYUDA!! :( Consulta con la extracción de Registros con el AS

[Erick_SS]

Hola gente les cuento mi problema.
Estoy realizando un formulario de búsqueda donde tengo las opciones para buscar los datos del Usuario. Ok, todo va bien cuando comparo los datos, el problema es este. La edad del Usuario la calculo en el Query de MySql a través de la fecha de su nacimiento (en formato: dd/mm/aaaa) y le asigno un AS AGEUSER el problema es que cuando selecciono en el formulario la edad por ejemplo entre 20 - 25 (años) no puedo poner un WHERE porque estoy utilizando un ALIAS.
El query q tengo es el siguiente:

SELECT *, SUBSTRING(NOW() FROM -19 FOR 4)-SUBSTR(f_nacimiento, -4) AS AGEUSER FROM boletines_usuarios WHERE genero = 'm';

esto me hace la consulta correctamente, pero como AGEUSER tiene un valor en tiempo de ejecución no puedo utilizar el WHERE AGEUSER (Q es el Alias que utilizamos) BETWEEN 20 and 25;

¿Que opciones me dan ustedes para poder obtener la Edad del Usuario en tiempo de Ejecución y compararla?

Ayudaaaa! plisss!

Se los agradezco de antemano.

[gnzsoloyo]

SI la fecha está realmente guardada como "dd/MM/aaaa", sería algo así:

Código MySQL:

SELECT *
FROM boletines_usuarios
WHERE
  genero = 'm' AND
  (TIMESTAMPDIFF(YEAR, STR_TO_DATE(f_nacimiento, '%d/%m/%Y'), CURDATE()) BETWEEN 20 AND 25);
 

Por un lado, no se debe usar VARCHAR ni CHAR para almacenar fechas. Es un error gravísimo por las complicaciones que trae luego para realizar consultas basadas en fechas. Hacerlo para disponer la fecha en un formato español es innecesario, ya que eso se resuelve en la aplicación, o bien en las consultas, usando la función DATE_FORMAT().
Además, al usar un VARCHAR o CHAR estás usando mucho más espacio de disco para almacenar una fecha que lo que usarías si el campo fuese DATE o DATETIME. El doble de espacio en disco.

Por otro lado, la cláusula AS es obsoleta. No se necesita y sólo se usa por compatibilidad hacia DBMSs antiguos.

Tip: Hay más formas de solucionar la consulta, pero esta sería una de las más eficientes.

[gnzsoloyo]

Para que veas el funcionamiento de STR_TO_DATE():

Código MySQL:

mysql> SELECT
    ->   TIMESTAMPDIFF(YEAR, STR_TO_DATE('12/5/1965', '%d/%m/%Y'), CURDATE()) 'Years';
+-------+
| Years |
+-------+
|    45 |
+-------+
1 row in set (0.00 sec)
 

[Erick_SS]

Iniciado por gnzsoloyo

SI la fecha está realmente guardada como "dd/MM/aaaa", sería algo así:

Código MySQL:

SELECT *
FROM boletines_usuarios
WHERE
  genero = 'm' AND
  (TIMESTAMPDIFF(YEAR, STR_TO_DATE(f_nacimiento, '%d/%m/%Y'), CURDATE()) BETWEEN 20 AND 25);
 

Por un lado, no se debe usar VARCHAR ni CHAR para almacenar fechas. Es un error gravísimo por las complicaciones que trae luego para realizar consultas basadas en fechas. Hacerlo para disponer la fecha en un formato español es innecesario, ya que eso se resuelve en la aplicación, o bien en las consultas, usando la función DATE_FORMAT().
Además, al usar un VARCHAR o CHAR estás usando mucho más espacio de disco para almacenar una fecha que lo que usarías si el campo fuese DATE o DATETIME. El doble de espacio en disco.

Por otro lado, la cláusula AS es obsoleta. No se necesita y sólo se usa por compatibilidad hacia DBMSs antiguos.

Tip: Hay más formas de solucionar la consulta, pero esta sería una de las más eficientes.

Hey Gracias gnzsoloyo
con respecto a la fecha y su formato tengo que cambiar el formato en la DB y en el formulario de Registro, porque en el formulario de registro está con ese formato y ya hay usuarios verdaderos registrados y tienen ese formato de fecha :s dd/mm/aaaa
es necesario cambiarlo?
??

[gnzsoloyo]

Hey Gracias gnzsoloyo
con respecto a la fecha y su formato tengo que cambiar el formato en la DB y en el formulario de Registro, porque en el formulario de registro está con ese formato y ya hay usuarios verdaderos registrados y tienen ese formato de fecha :s dd/mm/aaaa
es necesario cambiarlo?

En la base, si; en el formulario, NO.
El problema lo tendrás si la base ya está funcionando porque deberás planear una migración de formatos, y esos son temas complicados y peligrosos.
Tienes que entender un principio del desarrollo de software: La base es independiente de las aplicaciones. Siempre.
Cuando se diseña la base de datos lo que debe tenerse en cuenta es que de ella se pueda obtener toda la información que las aplicaciones requieran, pero el cómo la almacene y qué deba hacer para entregarla no es asunto de los programadores de aplicaciones. Es asunto del arquitecto de datos. Ellos sólo deben decirle qué necesitan, uno, como DBA, les entrega lo que quieren, pero el cómo lo obtienes es asunto tuyo. A los programadores no les debe interesar, en tanto la información sea fiable.
La idea de eso es que, dada la necesidad, puedas cambiar la aplicación sin necesidad de cambiar una línea de la base...
¿Se entiende?

Dicho esto, te aclaro: El formulario es asunto de programación. Interactúa con el usuario y debe, primordialmente, ser entendido por el usuario. Todo lo demás lo hace el programador por detrás del formulario... en la capa de negocios.
En tu caso la cosa es simple: Antes de ser enviados a la base, los datos deben ser validados y formateados. Punto. Para ello, tanto PHP, como ASP o cualquier lenguaje cuenta con funciones que les permite tomar una fecha escrita "dd/MM/aaaa" y transformarla en "aaaa-MM-dd".
Es absolutamente innecesario modificar el formulario. Todo cambio ebe hacerse una vez que el usuario clickea en "Guardar".

En el caso de PHP, por ejemplo, tiene muchas funciones de fecha y hora que puedes consultar en el manual on-line: Funciones de Fecha/Hora
Con el resto de los lenguajes es igual, mira el manual de referncia.

[Erick_SS]

Iniciado por gnzsoloyo

En la base, si; en el formulario, NO.
El problema lo tendrás si la base ya está funcionando porque deberás planear una migración de formatos, y esos son temas complicados y peligrosos.
Tienes que entender un principio del desarrollo de software: La base es independiente de las aplicaciones. Siempre.
Cuando se diseña la base de datos lo que debe tenerse en cuenta es que de ella se pueda obtener toda la información que las aplicaciones requieran, pero el cómo la almacene y qué deba hacer para entregarla no es asunto de los programadores de aplicaciones. Es asunto del arquitecto de datos. Ellos sólo deben decirle qué necesitan, uno, como DBA, les entrega lo que quieren, pero el cómo lo obtienes es asunto tuyo. A los programadores no les debe interesar, en tanto la información sea fiable.
La idea de eso es que, dada la necesidad, puedas cambiar la aplicación sin necesidad de cambiar una línea de la base...
¿Se entiende?

Dicho esto, te aclaro: El formulario es asunto de programación. Interactúa con el usuario y debe, primordialmente, ser entendido por el usuario. Todo lo demás lo hace el programador por detrás del formulario... en la capa de negocios.
En tu caso la cosa es simple: Antes de ser enviados a la base, los datos deben ser validados y formateados. Punto. Para ello, tanto PHP, como ASP o cualquier lenguaje cuenta con funciones que les permite tomar una fecha escrita "dd/MM/aaaa" y transformarla en "aaaa-MM-dd".
Es absolutamente innecesario modificar el formulario. Todo cambio ebe hacerse una vez que el usuario clickea en "Guardar".

En el caso de PHP, por ejemplo, tiene muchas funciones de fecha y hora que puedes consultar en el manual on-line: [URL="http://ar.php.net/manual/es/ref.datetime.php"]Funciones de Fecha/Hora[/URL]
Con el resto de los lenguajes es igual, mira el manual de referncia.

Ok, muchas Gracias por tu explicación y por tu tiempo.
Te cuento que ya utilicé el codigo que me proporcionaste y el probarlo todo me salió excelente!!!!

Gracias de Nuevo.