Dette fortsætter med at samle flere stemmer, selv flere år senere, og derfor er jeg nødt til at opdatere det til moderne versioner af Sql Server. For SQL Server 2008 og nyere er det enkelt:
cast(getDate() As Date)
Bemærk, at de sidste tre afsnit nær bunden stadig gælder, og du er ofte nødt til at træde et skridt tilbage og finde en måde at undgå rollebesætningen i første omgang.
Men der er også andre måder at opnå dette på. Her er de mest almindelige.
Den korrekte måde (nyt siden SQL Server 2008):
cast(getdate() As Date)
Den korrekte måde (gammel):
dateadd(dd, datediff(dd,0, getDate()), 0)
Dette er ældre nu, men det er stadig værd at vide, fordi det også nemt kan tilpasse sig andre tidspunkter, f.eks. månedens første øjeblik, minut, time eller år.
Denne korrekte måde bruger dokumenterede funktioner, der er en del af ansi-standarden, og som med garanti virker, men det kan være noget langsommere. Det fungerer ved at finde, hvor mange dage der er fra dag 0 til den aktuelle dag, og tilføje det mange dage tilbage til dag 0. Det vil fungere, uanset hvordan dit datetime er gemt, og uanset hvilken lokalitet du har.
Den hurtige måde:
cast(floor(cast(getdate() as float)) as datetime)
Dette virker, fordi datetime-kolonner er gemt som 8-byte binære værdier. Kast dem til at flyde, gulv dem for at fjerne brøken, og tidsdelen af værdierne er væk, når du kaster dem tilbage til datetime. Det hele er bare lidt skiftende uden kompliceret logik, og det er meget hurtig.
Vær opmærksom på, at dette afhænger af en implementeringsdetalje, som Microsoft til enhver tid kan ændre, selv i en automatisk tjenesteopdatering. Den er heller ikke særlig bærbar. I praksis er det meget usandsynligt, at denne implementering snart vil ændre sig, men det er stadig vigtigt at være opmærksom på faren, hvis du vælger at bruge den. Og nu hvor vi har mulighed for at caste som en date, er det sjældent nødvendigt.
Den forkerte vej:
cast(convert(char(11), getdate(), 113) as datetime)
Den forkerte måde fungerer ved at konvertere til en streng, afkorte strengen og konvertere tilbage til en dato og klokkeslæt. Det er forkert , af to grunde:1) det virker måske ikke på tværs af alle lokaliteter og 2) det handler om den langsomst mulige måde at gøre dette på... og ikke kun en lille smule; det er ligesom en størrelsesorden eller to langsommere end de andre muligheder.
Opdater Dette har fået nogle stemmer på det seneste, og så vil jeg tilføje til det, at siden jeg postede dette, har jeg set nogle ret solide beviser for, at Sql Server vil optimere ydeevneforskellen mellem "korrekt" måde og den "hurtige" måde, hvilket betyder, at du nu bør favorisere førstnævnte.
I begge tilfælde vil du skrive dine forespørgsler for at undgå behovet for at gøre dette i første omgang . Det er meget sjældent, at du skal udføre dette arbejde på databasen.
De fleste steder er databasen allerede din flaskehals. Det er generelt den server, der er den dyreste at tilføje hardware til for at forbedre ydeevnen og den sværeste at få disse tilføjelser rigtigt (du skal f.eks. balancere diske med hukommelse). Det er også det sværeste at skalere udad, både teknisk og fra et forretningsmæssigt synspunkt; det er meget lettere teknisk at tilføje en web- eller applikationsserver end en databaseserver, og selvom det var falsk, betaler du ikke $20.000+ pr. serverlicens for IIS eller apache.
Pointen, jeg prøver at gøre, er, at når det er muligt, skal du udføre dette arbejde på applikationsniveau. Den eneste tidspunktet du nogensinde skulle finde på at afkorte en datetime på SQL Server er, når du skal gruppere efter dag, og selv da burde du nok have en ekstra kolonne sat op som en beregnet kolonne, vedligeholdt ved indsættelse/opdateringstidspunkt eller vedligeholdt i applikationen logik. Få dette indeksbrydende, cpu-tunge arbejde fra din database.