Questo continua a raccogliere frequentemente ulteriori voti, anche diversi anni dopo, e quindi ho bisogno di aggiornarlo per le versioni moderne di SQL Server. Per SQL Server 2008 e versioni successive, è semplice:
cast(getDate() As Date)
Si noti che gli ultimi tre paragrafi nella parte inferiore si applicano ancora e spesso è necessario fare un passo indietro e trovare un modo per evitare il cast in primo luogo.
Ma ci sono anche altri modi per farlo. Ecco i più comuni.
Il modo corretto (novità da SQL Server 2008):
cast(getdate() As Date)
Il modo corretto (vecchio):
dateadd(dd, datediff(dd,0, getDate()), 0)
Ora è più vecchio, ma vale comunque la pena sapere perché può anche adattarsi facilmente ad altri punti temporali, come il primo momento del mese, minuto, ora o anno.
Questo modo corretto utilizza funzioni documentate che fanno parte dello standard ansi e sono garantite per funzionare, ma può essere un po 'più lento. Funziona trovando quanti giorni ci sono dal giorno 0 al giorno corrente e aggiungendo quanti giorni al giorno 0. Funzionerà indipendentemente dal tempo di archiviazione dei dati e dalle impostazioni locali.
Il modo veloce:
cast(floor(cast(getdate() as float)) as datetime)
Ciò funziona perché le colonne datetime sono archiviate come valori binari a 8 byte. Lanciali per fluttuare, pavimentali per rimuovere la frazione e la parte temporale dei valori scompare quando li rilasci in datetime. Tutto sta cambiando un po 'senza una logica complicata ed è molto veloce.
Tieni presente che questo si basa su un dettaglio di implementazione che Microsoft è libera di modificare in qualsiasi momento, anche in un aggiornamento automatico del servizio. Inoltre non è molto portatile. In pratica, è molto improbabile che questa implementazione cambierà presto, ma è comunque importante essere consapevoli del pericolo se si sceglie di usarlo. E ora che abbiamo la possibilità di scegliere come data, raramente è necessario.
La strada sbagliata:
cast(convert(char(11), getdate(), 113) as datetime)
Il modo sbagliato funziona convertendosi in una stringa, troncando la stringa e convertendo nuovamente in un datetime. È sbagliato , per due motivi: 1) potrebbe non funzionare in tutti i locali e 2) è il modo più lento possibile per farlo ... e non solo un po '; è come un ordine di grandezza o due più lento delle altre opzioni.
Aggiornamento Questo ha ottenuto recentemente alcuni voti, e quindi voglio aggiungere ad esso che da quando ho pubblicato questo ho visto alcune prove abbastanza solide che Sql Server ottimizzerà la differenza di prestazioni tra il modo "corretto" e il modo "veloce" , il che significa che ora dovresti favorire il primo.
In entrambi i casi, vuoi scrivere le tue domande per evitare la necessità di farlo in primo luogo . È molto raro che tu debba fare questo lavoro sul database.
Nella maggior parte dei casi, il database è già il collo di bottiglia. In genere è il server a cui è più costoso aggiungere hardware per migliorare le prestazioni e quello più difficile per ottenere quelle aggiunte giuste (ad esempio, è necessario bilanciare i dischi con la memoria). È anche il più difficile da ridimensionare verso l'esterno, sia tecnicamente che dal punto di vista aziendale; è tecnicamente molto più semplice aggiungere un server Web o applicativo rispetto a un server database e anche se fosse falso non si pagano $ 20.000 + per licenza server per IIS o apache.
Il punto che sto cercando di sottolineare è che quando possibile dovresti fare questo lavoro a livello di applicazione. L' unica volta in cui dovresti mai ritrovarti a troncare un datetime su Sql Server è quando devi raggruppare di giorno in giorno, e anche allora dovresti probabilmente avere una colonna aggiuntiva impostata come colonna calcolata, mantenuta al momento dell'inserimento / aggiornamento o mantenuta nella logica dell'applicazione. Rimuovi dal database questo lavoro che rompe l'indice e fa molto lavoro.