agrupar por campos calculados

[pabloturchi]

Hola a todos. Tengo el siguiente problema, tengo un select de una tabla (en realidad de dos) en la que debo agrupar datos para dar todales, pero por campos calculados. Por ejemplo, la fecha del datetime y una condicion de la hora del datetime (mañana o tarde). O sea, por ejemplo 2008-07-12 10:00 y 2008-07-12 16:00 no van juntas porque si bien la fecha es la misma el rango de horas no. Hay otros campos calculados que van en el group by pero veo que no puedo ponerlos. Alguna idea??? Desde ya muchas gracias.

[iislas]

Pues no me quedo muy claro, pero si la hora de la fecha es entre las 0 y las 11:59, son DIAS, y si pasa de estas, son NOCHES, me queda claro, ¿es eso?

[alxrex]

Que tal si usas 2 Consultas

WHERE fecha BETWEEN 'aaaa/mm/dd: hh:mm:ss' AND 'aaaa/mm/dd: hh:mm:ss'
si tu consideras que la mañana es

WHERE fecha BETWEEN 'aaaa/mm/dd: 06:00:00 a. m.' AND 'aaaa/mm/dd: 11:59:59 a.m.'

Tarde

WHERE fecha BETWEEN 'aaaa/mm/dd: 12:00:00 p. m.' AND 'aaaa/mm/dd: 10:00:00 p.m.'


Y el mismo sql te obliga a agrupar por algunos campor
GROUP BY FECHA

[iislas]

Opssss, yo no utilizaria BETWEEN para comparar fechas, pero es a gusto del cliente.

[pabloturchi]

Gracias a todos porque use un poco de cada cosa que me dijeron y la cosa funciono bien. Muchas gracias.

[flaviovich]

Iniciado por iislas

Opssss, yo no utilizaria BETWEEN para comparar fechas, pero es a gusto del cliente.

iislas, hace tiempo que vengo leyendo esto. ¿Por qué no fundamentas lo que dices? Pon ejemplos. De repente es la versión que usas.

[iislas]

No es por la version, he leido articulos al respecto sobre le manejo de fechas en SQL Server (y otros motores).

Aqui 2 muy interesantes:

http://www.mug.org.ar/SQL/ArticSQL/240.aspx
http://www.crostonectingpeople.com/2...sql-sever.html

Bueno y me tome la libertad de hacer algunos ejercicios con MILLONES de registros y ni hablar, el formato ANSI con >= y <=, va mucho mas rapido.

Saludos

[flaviovich]

Muy interesante, pero creo que el principal problema que tocan (el idioma) se puede solucionar facilmente con SET LANGUAGE y ya no seria necesario cambiar a ANSI, un formato (o estandar) que a mi parecer no es agradable a la vista.
Ahora, en cuanto a la rapidez no puedo decir porque no he comparado ambas formas, pero si tu has probado, entonces te creo.
Gracias por el dato.

[iislas]

flaviovich

El formato ANSI, es para evitar problemas de migracion de bases de datos o escalonamiento hacia otros motores, que sea de forma "trasparente" y no tengas quebraderos de cabeza por compatibilidad de datos.

Saludos.

[Andres95]

De acuerdo con el uso de formato ANSI...

me ha ahorrado mucho tiempo de modificaciones y dolores de cabeza...

Saludos!

[flaviovich]

Iniciado por iislas

flaviovich

El formato ANSI, es para evitar problemas de migracion de bases de datos o escalonamiento hacia otros motores, que sea de forma "trasparente" y no tengas quebraderos de cabeza por compatibilidad de datos.

Saludos.

A eso queria llegar: ANSI no es obligatorio para consulta de busquedas por fecha, a menos que tengas millones de registros (segun tus palabras). Pero si es recomendable para evitar "dolores de cabeza".
En fin, no pretendo abrir un debate sobre el uso de ANSI, sino que lo que quiero decir es, que no es bueno instigar su uso.
Eso es todo :)

[Andres95]

Es correcto, no se instiga; solo se recomienda. Por experiencia propia.

Saludos!

[iislas]

Exacto, se recomimenda, como el uso del CONDON (¿?), pero no se obliga............Saludos (No more comments)