fecha posterior

[cucuru]

hola a todos! ¿hay alguna función que busque el máximo entre varias fechas?

no están todas en la misma columna, sino en columnas diferentes, es el max(fechaColumna1, fechaColumna2), ¿eso puede hacerse?

Gracias!

[cucuru]

Lo he encontrado! y es muy útil! por si alguien lo necesita es:

select greatest(max(fechaAlquiler),max(fechaDevolucion)) from alquileres;

http://www.jordigirones.com/174-valo...ila-mysql.html

[gnzsoloyo]

Es una buena solución. casi nunca nos acordamos de esa función que puede ser la más eficiente en cierto tipo de datos, como enteros, flotantes, caracteres.
La salvedad que hay que notar es que como la función sólo está optimizada para esos tres tipos básicos de datos, con todos los demás realiza una conversión implícita a caracteres, y evalúa los datos como tales. Como en el caso de las fechas puede terminar haciendo una conversión doble, la función puede eventualmente tener un mal impacto en la performance de consultas con cantidades masivas de datos.
En tanto no hablemos de millones de registros, no debería haber problemas.

[cucuru]

Conversión doble?

Tengo mis fechas en formato americano (YYYY-MM-DD) por lo que no debería haber problema, no???

me aconsejas utilizar timestamps?

Gracias!

[gnzsoloyo]

Eso no es formato americano (ese sería MM-dd-aaaa).
Es formato estandar de las bases de datos.

Lo de conversiones implícitas me parece que no lo entendiste. Deberías leer el manual de referencia de MySQL un poco más (http://dev.mysql.com/doc/refman/5.0/...onversion.html), porque es un problema que afecta los resultados de las consultas.

MySQL hace conversiones implícitas (lo quieras o no) en ciertos contextos donde se espera que se usen los datos en determinadas formas.
Una de esas conversiones, por ejemplo, es entre una cadena que contiene un número y una columna o variable numérica:

Código MySQL:

SET NumericColumn = '12345'
 

"12345" en este caso es una cadena de texto, entonces MySQL la convierte en un número y la almacena.
A la inversa también lo hace:

Código MySQL:

SET VarcharColumn = 12345
 

Por eso, por ejemplo se puede hacer un WHERE en este contexto:

Código MySQL:

WHERE DateColumn = '2011-05-31'
 

donde se compara una columna de fecha con una cadena de texto que contiene una fecha. MySQL directamente convierte la cadena en fecha antes de hacer la comparación (la fecha tiene mayor jerarquía y la cadena cumple con el formato).

Ahora bien, yendo a GREATEST(), veamos lo que dice el manual:

GREATEST(value1,value2,...)
Con dos o más argumentos, retorna el argumento mayor (con valor mayor). Los argumentos se comparan usando las mismas reglas que para LEAST().

Esto nos indica que debemos ver cómo lo maneja LEAST():

LEAST(value1,value2,...)
Con dos o más argumentos, retorna el argumento menor (con un valor menor). Los argumentos se comparan usando las siguientes reglas:

- Si el valor retornado se usan en un contexto INTEGER o todos los argumentos son enteros, se comparan como enteros.
- Si el valor retornado se usa en un contexto REAL o todos los argumentos son reales, se comparan como reales.
- Si algún argumento es una cadena de caracteres sensible a mayúsculas, los argumentos se comparan como cadenas sensibles a mayúsculas.
- En cualquier otro caso, los argumentos se comparan como cadenas no sensibles a mayúsculas.

Código MySQL:

mysql> SELECT LEAST(2,0);
        -> 0
mysql> SELECT LEAST(34.0,3.0,5.0,767.0);
        -> 3.0
mysql> SELECT LEAST('B','A','C');
        -> 'A'
 

Tenga en cuenta que las reglas de conversión precedentes pueden producir resultados extraños en algunos casos extremos:

Código MySQL:

mysql> SELECT CAST(LEAST(3600, 9223372036854775808.0) as SIGNED);
    -> -9223372036854775808
 

Esto ocurre porque MySQL lee 9223372036854775808.0 en un contexto entero. La representación entera no es lo bastante buena para tratar el valor, así que lo cambia a entero con signo.

Entonces, como una fecha noes un entero, ni un float, ni una cadena de texto sensible a mayúsculas, entonces queda en el cuarto caso: Se lo toma como una cadena de texto común (no sensible), por lo cual se aplican las reglas de conversión implícita: los valores comparados se convierten a cadena (según el formato DATE o DATETIME), se comparan y luego, dependiendo del contexto, se dejará como cadena o se volverá a convertir en una fecha, según el caso.

¿Se entiende la idea?

Todo esto no hace mucho problema cuando trabajas con algunos miles de registros. El overhead que le agregan estas conversiones es demasiado poco para notarlo, y se pierde en el tiempo que el sistema usa para generar otras cosas de la consulta.
Pero cuando trabajas con millones de registros, y esa conversión la debe hacer contra todos los registros... Bueno, allí se empieza a notar, y puede que usar algo más complicado que un GREATEST() termine funcionando mejor, porque no requiere de conversiones.

En definitiva: Si vas a trabajar con miles de registros, no hay problema. Si te enfrentas con millones, deberás analizar bien la performance de las funciones que utilizas para escoger la mejor opción.

Nota: Yo ya sufrí estas diferencias de performance, porque las bases que manejo habitualmente suelen tener algunas tablas con 50 a 70 millones de registros (de 150 bytes cada registro... haz la cuenta), y algunas consultas usan hasta 6.000.000 para obtener resumenes. Un asco