Dit blijft regelmatig extra stemmen verzamelen, zelfs enkele jaren later, en dus moet ik het updaten voor moderne versies van Sql Server. Voor SQL Server 2008 en later is het eenvoudig:
cast(getDate() As Date)
Merk op dat de laatste drie alinea's onderaan nog steeds van toepassing zijn, en dat je vaak een stap terug moet doen en een manier moet vinden om de cast in de eerste plaats te vermijden.
Maar er zijn ook andere manieren om dit te bereiken. Dit zijn de meest voorkomende.
Op de juiste manier (nieuw sinds Sql Server 2008):
cast(getdate() As Date)
De juiste manier (oud):
dateadd(dd, datediff(dd,0, getDate()), 0)
Dit is nu ouder, maar het is nog steeds de moeite waard om te weten omdat het ook gemakkelijk kan worden aangepast voor andere tijdstippen, zoals het eerste moment van de maand, minuut, uur of jaar.
Deze correcte manier maakt gebruik van gedocumenteerde functies die deel uitmaken van de ansi-standaard en die gegarandeerd werken, maar het kan wat langzamer zijn. Het werkt door uit te zoeken hoeveel dagen er zijn vanaf dag 0 tot de huidige dag, en dat aantal dagen toe te voegen aan dag 0. Het werkt ongeacht hoe uw datetime is opgeslagen en ongeacht uw landinstelling.
De snelle manier:
cast(floor(cast(getdate() as float)) as datetime)
Dit werkt omdat datetime-kolommen worden opgeslagen als 8-byte binaire waarden. Werp ze om te zweven, vloer ze om de breuk te verwijderen, en het tijdsgedeelte van de waarden is verdwenen als je ze terug naar datetime cast. Het is allemaal een beetje verschuivend zonder ingewikkelde logica en het is erg snel.
Houd er rekening mee dat dit afhankelijk is van een implementatiedetail dat Microsoft op elk moment kan wijzigen, zelfs bij een automatische service-update. Het is ook niet erg draagbaar. In de praktijk is het zeer onwaarschijnlijk dat deze implementatie snel zal veranderen, maar het is toch belangrijk om je bewust te zijn van het gevaar als je ervoor kiest om het te gebruiken. En nu we de mogelijkheid hebben om als datum te casten, is dat zelden nodig.
Op de verkeerde manier:
cast(convert(char(11), getdate(), 113) as datetime)
De verkeerde manier werkt door te converteren naar een string, de string af te kappen en terug te converteren naar een datetime. Het is fout , om twee redenen:1) het werkt misschien niet op alle locaties en 2) het is ongeveer de langzaamst mogelijke manier om dit te doen ... en niet slechts een klein beetje; het is een orde van grootte of twee langzamer dan de andere opties.
Bijwerken Dit heeft de laatste tijd wat stemmen gekregen, en daarom wil ik eraan toevoegen dat sinds ik dit heb gepost, ik behoorlijk solide bewijs heb gezien dat Sql Server het prestatieverschil tussen de "juiste" manier en de "snelle" manier zal optimaliseren, wat betekent dat je nu de voorkeur moet geven aan de eerste.
In beide gevallen wilt u uw vragen schrijven om te voorkomen dat u dit überhaupt hoeft te doen . Het komt zelden voor dat u dit werk aan de database doet.
Op de meeste plaatsen is de database al je bottleneck. Het is over het algemeen de server die het duurst is om hardware aan toe te voegen voor prestatieverbeteringen en de moeilijkste om die toevoegingen goed te krijgen (je moet bijvoorbeeld schijven in evenwicht brengen met geheugen). Het is ook het moeilijkst om naar buiten te schalen, zowel technisch als zakelijk; het is technisch gezien veel gemakkelijker om een web- of applicatieserver toe te voegen dan een databaseserver en zelfs als dat niet waar zou zijn, betaal je geen $20.000+ per serverlicentie voor IIS of apache.
Het punt dat ik probeer te maken is dat je dit werk waar mogelijk op applicatieniveau moet doen. De alleen de tijd dat je ooit zou merken dat je een datetime op Sql Server inkort, is wanneer je per dag moet groeperen, en zelfs dan zou je waarschijnlijk een extra kolom moeten hebben die is ingesteld als een berekende kolom, onderhouden op het moment van invoegen / bijwerken of onderhouden in de toepassing logica. Haal dit indexbrekende, cpu-zware werk uit uw database.