Ver Mensaje Individual
  #5 (permalink)  
Antiguo 14/06/2011, 06:06
Avatar de gnzsoloyo
gnzsoloyo
Moderador criollo
 
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 16 años, 5 meses
Puntos: 2658
Respuesta: fecha posterior

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:
Ver original
  1. 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:
Ver original
  1. SET VarcharColumn = 12345
Por eso, por ejemplo se puede hacer un WHERE en este contexto:
Código MySQL:
Ver original
  1. 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:
Cita:
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():
Cita:
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:
Ver original
  1. mysql> SELECT LEAST(2,0);
  2.         -> 0
  3. mysql> SELECT LEAST(34.0,3.0,5.0,767.0);
  4.         -> 3.0
  5. mysql> SELECT LEAST('B','A','C');
  6.         -> 'A'
Tenga en cuenta que las reglas de conversión precedentes pueden producir resultados extraños en algunos casos extremos:
Código MySQL:
Ver original
  1. mysql> SELECT CAST(LEAST(3600, 9223372036854775808.0) as SIGNED);
  2.     -> -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
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)