Esto continúa reuniendo con frecuencia votos adicionales, incluso varios años después, por lo que necesito actualizarlo para las versiones modernas de SQL Server. Para Sql Server 2008 y posterior, es simple:
cast(getDate() As Date)
Tenga en cuenta que los últimos tres párrafos cerca de la parte inferior todavía se aplican, y a menudo necesita 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. Aquí están los más comunes.
La forma correcta (nuevo desde Sql Server 2008):
cast(getdate() As Date)
La forma correcta (antigua):
dateadd(dd, datediff(dd,0, getDate()), 0)
Esto es más antiguo ahora, pero aún vale la pena saberlo porque también puede adaptarse 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 algo más lento. Funciona al encontrar cuántos días hay desde el día 0 hasta el día actual, y agregar esos días de regreso al día 0. Funcionará sin importar cómo se almacene su fecha y hora y cuál sea su ubicación.
La manera 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. Conviértalos en flotantes, vuélvalos a piso para eliminar la fracción y la parte de tiempo de los valores desaparecerá cuando los devuelva a la fecha y hora. Todo cambia un poco sin una lógica complicada y es muy rápido.
Tenga en cuenta que esto se basa en 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 en el corto plazo, pero aún es importante tener en cuenta el 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 convirtiendo a una cadena, truncando la cadena y volviendo a convertir a una fecha y hora. Está mal , por dos razones: 1) podría no funcionar en todos los entornos locales y 2) se trata de 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.
Actualización Esto ha estado recibiendo algunos votos últimamente, por lo que quiero agregar que desde que publiqué esto, he visto algunas pruebas bastante sólidas de que SQL Server optimizará la diferencia de rendimiento entre la forma "correcta" y la "rápida". , lo que significa que ahora deberías favorecer a los primeros.
En cualquier caso, desea escribir sus consultas para evitar la necesidad de hacerlo en primer lugar . Es muy raro que haga este trabajo en la base de datos.
En la mayoría de los lugares, la base de datos ya es su cuello de botella. En general, es el servidor más caro para agregar hardware para mejorar el rendimiento y el más difícil para lograr esas adiciones correctamente (por ejemplo, debe equilibrar los discos con la memoria). También es el más difícil de escalar hacia afuera, tanto técnicamente como desde el punto de vista comercial; técnicamente es mucho más fácil 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 por IIS o apache.
El punto que estoy tratando de hacer es que, siempre que sea posible, debe hacer este trabajo a nivel de aplicación. El único momento en 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 el momento de inserción / actualización, o mantenida en lógica de aplicación. Saque de su base de datos este trabajo de alto índice de procesamiento de la CPU.