<p>Strictement, la méthode <code>a</code> est la moins gourmande en ressources :</p>
<pre><code class="lang-auto">a) select DATEADD(dd, DATEDIFF(dd, 0, getdate()), 0)
</code></pre>
<p>Prouvée moins gourmande en CPU pour la même durée totale sur un million de lignes par quelqu’un qui avait vraiment trop de temps libre : <a href="https://stackoverflow.com/questions/133081/most-efficient-way-in-sql-server-to-get-date-from-datetime">La manière la plus efficace dans SQL Server d’obtenir une date à partir de date+heure ?</a></p>
<p>J’ai vu un test similaire ailleurs avec des résultats similaires aussi.</p>
<p>Je préfère DATEADD/DATEDIFF parce que :</p>
<ul>
<li>varchar est sujet aux problèmes de langue/format de date</li>
</ul>
<p>Exemple : <a href="https://stackoverflow.com/q/3596663/27535">Pourquoi mon expression CASE est-elle non déterministe ?</a></p>
<ul>
<li>
<p>float repose sur le stockage interne</p>
</li>
<li>
<p>cela s’étend pour calculer le premier jour du mois, demain, etc. en changeant la base « 0 »</p>
</li>
</ul>
<p><strong>Modification, octobre 2011</strong></p>
<p>Pour SQL Server 2008+, vous pouvez faire un CAST vers <code>date</code>, c’est-à-dire <code>CAST(getdate() AS date)</code>. Ou simplement utiliser le type de données <code>date</code> pour ne pas avoir de <code>time</code> à supprimer.</p>
<p><strong>Modification, janvier 2012</strong></p>
<p>Un exemple concret de la flexibilité de cette approche : <a href="https://stackoverflow.com/questions/8722022/need-to-calculate-by-rounded-time-or-date-figure-in-sql-server/8723311#8723311">Besoin de calculer par temps arrondi ou chiffre de date dans SQL Server</a></p>
<p><strong>Modification, mai 2012</strong></p>
<p>N’utilisez pas ceci dans les clauses WHERE et similaires sans réfléchir : ajouter une fonction ou un CAST à une colonne invalide l’utilisation de l’index. Voir le numéro 2 ici <a href="http://www.simple-talk.com/sql/t-sql-programming/ten-common-sql-programming-mistakes/">Erreurs courantes de programmation SQL</a></p>
<p>Cependant, ceci contient un exemple où les versions ultérieures de l’optimiseur SQL Server gèrent correctement le CAST vers date, mais <em>en général</em> ce sera une mauvaise idée…</p>
<p><strong>Modification, septembre 2018, pour datetime2</strong></p>
<pre><code class="lang-auto">DECLARE @datetime2value datetime2 = '02180912 11:45' --this is deliberately within datetime2, year 0218
DECLARE @datetime2epoch datetime2 = '19000101'
select DATEADD(dd, DATEDIFF(dd, @datetime2epoch, @datetime2value), @datetime2epoch)
</code></pre>
