Esto continúa reuniendo votos adicionales con frecuencia, incluso varios años después, por lo que necesito actualizarlo para las versiones modernas de Sql Server. Para Sql Server 2008 y versiones posteriores, es simple:
cast(getDate() As Date)
Tenga en cuenta que los últimos tres párrafos cerca de la parte inferior aún se aplican y, a menudo, debe dar un paso atrás y encontrar una manera de evitar el yeso en primer lugar.
Pero también hay otras formas de lograr esto. Estos son los más comunes.
La forma correcta (nueva desde Sql Server 2008):
cast(getdate() As Date)
La forma correcta (antigua):
dateadd(dd, datediff(dd,0, getDate()), 0)
Ahora es más antiguo, pero vale la pena conocerlo porque también se puede adaptar fácilmente a otros puntos de tiempo, como el primer momento del mes, minuto, hora o año.
Esta forma correcta utiliza funciones documentadas que son parte del estándar ansi y se garantiza que funcionan, pero puede ser un poco más lento. Funciona encontrando cuántos días hay desde el día 0 hasta el día actual, y sumando esa cantidad de días al día 0. Funcionará sin importar cómo se almacene su fecha y hora y sin importar cuál sea su configuración regional.
La forma rápida:
cast(floor(cast(getdate() as float)) as datetime)
Esto funciona porque las columnas de fecha y hora se almacenan como valores binarios de 8 bytes. Transmítalos para que floten, bájelos para eliminar la fracción y la parte de tiempo de los valores desaparecerá cuando los vuelva a convertir en fecha y hora. Todo cambia poco a poco sin una lógica complicada y es muy rápido.
Tenga en cuenta que esto depende de un detalle de implementación que Microsoft puede cambiar en cualquier momento, incluso en una actualización automática del servicio. Tampoco es muy portátil. En la práctica, es muy poco probable que esta implementación cambie pronto, pero aún así es importante ser consciente del peligro si elige usarla. Y ahora que tenemos la opción de emitir como fecha, rara vez es necesario.
La forma incorrecta:
cast(convert(char(11), getdate(), 113) as datetime)
La forma incorrecta funciona al convertir a una cadena, truncar la cadena y volver a convertirla en una fecha y hora. Está mal , por dos razones:1) es posible que no funcione en todas las configuraciones regionales y 2) es la forma más lenta posible de hacer esto... y no solo un poco; es como un orden de magnitud o dos más lento que las otras opciones.
Actualizar Esto ha estado recibiendo algunos votos últimamente, por lo que quiero agregar que desde que publiqué esto, he visto evidencia bastante sólida de que Sql Server optimizará la diferencia de rendimiento entre la forma "correcta" y la forma "rápida". lo que significa que ahora deberías preferir lo primero.
En cualquier caso, desea escribir sus consultas para evitar la necesidad de hacer esto en primer lugar . Es muy raro que deba hacer este trabajo en la base de datos.
En la mayoría de los lugares, la base de datos ya es su cuello de botella. Por lo general, el servidor es el más caro para agregar hardware para mejorar el rendimiento y el más difícil de hacer bien esas adiciones (tiene que equilibrar los discos con la memoria, por ejemplo). También es el más difícil de escalar hacia el exterior, tanto desde el punto de vista técnico como empresarial; es mucho más fácil técnicamente agregar un servidor web o de aplicaciones que un servidor de base de datos e incluso si eso fuera falso, no paga más de $ 20,000 por licencia de servidor para IIS o apache.
El punto que estoy tratando de hacer es que, siempre que sea posible, debe hacer este trabajo en el nivel de la aplicación. El único El tiempo en el que debería encontrarse truncando una fecha y hora en Sql Server es cuando necesita agrupar por día, e incluso entonces probablemente debería tener una columna adicional configurada como una columna calculada, mantenida en tiempo de inserción/actualización, o mantenida en la aplicación lógica. Saca de tu base de datos este trabajo pesado de CPU que rompe índices.
