SQL Server Datetime vs Datetime2

DET er mange tids-Og datoformater I SQL Server med forskjellige områder, nøyaktigheter, lagringsstørrelser og brukerdefinerte brøkdels andre presisjoner.

Nedenfor er en kort oversikt:

vi ønsker å fokusere på sammenligning av datetime og datetime2 format. I mitt nåværende selskap møter jeg mange eldre tabeller som bruker datetime. Datetime2 ble først introdusert I SQL Server 2008. Men jeg tror at noen utviklere rett og slett ikke vet om fordeler og ulemper ved datetime2.

Datetime

La oss først diskutere datetime litt. Som du kan se ovenfor, trenger den 8 byte lagringsplass og har et område fra 1753-01-01 til 9999-12-31. Spesielt har den en kort rekkevidde bakover. Dette skyldes At Storbritannia flyttet Fra Den Juliske Til Den Gregorianske kalenderen i 1752 ved å hoppe over noen dager. For å være mer presis ble 2. September 1752 etterfulgt av 14. September 1752. Fordi en dato før 1753 ville være tvetydig, er datetime-typen ikke gyldig før 1753. En annen ganske merkbar egenskap av datetime datatype er nøyaktigheten av 0,00333 sekunder som faktisk er 1/300 av et sekund.

dette virker litt rart. Vi har ikke millisekund nøyaktighet med datetime. OK, men hvorfor? La oss analysere datetime datatypen i dybden. I en datetime bruker vi 4 byte for dato og 4 byte for tid. Hvordan fungerer det nøyaktig? La oss ta en titt.

DECLARE @test DATETIME = '2015-11-29 10:00:00.000';SELECT CAST(@test as varbinary(8))> 0x0000A55F00A4CB80

0x0000A55F00A4CB80 er heksadesimal. La oss skille de 8 byte i to deler. Først datoen. 0x0000A55F representerer datoen. I desimal er det 42335. Det er antall dager gått siden 1900-01-01. Bevis:

SELECT DATEADD(DD,42335,'1900-01-01')> 2015-11-29

Nå for tiden har vi de siste 4 byte 0xA4CB80oversatt til desimal er det 10800000. Det betyr 10800000 flått fra midnatt på. Husk jeg sa noyaktigheten er 1/300 av et sekund? Det skyldes det faktum at datetime lagrer tiden i flått. Så 10800000 flått siden midnatt betyr 10800000 ganger 1/300 av et sekund. La oss beregne litt.

Så vi har nøyaktig 10 timer fra midnatt, og det oversetter perfekt til 10: 00: 00. Kombinert med datoen har vi 2015-11-29 10: 00: 00.

Husk at datetime bruker alltid 8 byte med lagring og også huske på at de første fire byte som representerer datoen kan være negativ (2complement) siden datoen kan være før 1900. For eksempel, i 1890-11-29 får du de første 4 byte som 0xFFFFF308, som oversettes som 32-bit 2-komplement til -3320. Og 3320 substracted fra 1900-01-01 er akkurat 1890-11-29.

datetime2

Alle dato og klokkeslett datatyper introdusert MED SQL Server 2008 har en helt ny lagringstype som vi vil undersøke nå. Datetime2 datatypen bruker 6 til 8 byte avhengig av milisekund presisjon.

DECLARE @test DATETIME2(3) = '2015-11-29 10:00:00.000';SELECT CAST(@test as varbinary(8))> 0x0300512502BA3A0B

Denne gangen blir det litt mer komplisert. I alle nye datetime datatyper representerer de TRE siste byte datoen. Det skyldes en endring av byte rekkefølge. Så datetime lagres som little endian, noe som betyr at den viktigste byten er til venstre, mens i big endian er den viktigste byten lagret på høyre side.

det betyr at når vi tar 0x0300512502BA3A0B, er datoen ikke 0xBA3A0B, men 0x0B3ABA, siden en byte er 2 heksadesimale sifre.

Igjen med matematikken: 0x0b3aba representerer desimal 735930. Dette er akkurat den datoen vi ønsket:

SELECT DATEADD(DD,735930,CAST('0001-01-01' as date))> 2015-11-29

Nå som byte konverteres, kan vi bare ta de siste byte av liten endian representasjon som er 0x0225510003. Husk at den aller siste byten i little endian (det er den første byten i original big endian) er presisjonen oppgitt. Som du kan se definerte vi datetime2 (3) det betyr at vår aller siste byte er 0x03.

Gjør matematikken: 0x02255100 er i desimal 36000000. Siden vi brukte presisjon 3, som betyr 3 sifret presisjon, beregner vi sekundene først ved å dele tallet vårt med 10 til presisjonskraften som i vårt tilfelle er 103.

dette oversetter også perfekt til 10 timer 0 minutter 0 sekunder akkurat som nevnt.

datetime vs datetime2

Endelig en enkel og vanlig sammenligning mellom de to datatypene.

datetime datetime2
maks presis odd presisjon av 1/300 100 nanosekund presisjon
brukerdefinert presisjon nei ja fra 0 til 7
lagringsplass alltid 8 byte 6 – 8 byte avhengig av presisjon
brukbar med + or – operatør ja nei, bruk datediff, dateadd etc.
sql Standard kompatibel nei ja

så generelt ser du datetime bruker potensielt mer lagringsplass, har en lavere og merkelig presisjon, har lavere rekkevidde og er ikke kompatibel med SQL-Standarden, noe som gjør at koden oppfører seg annerledes på forskjellige DBMS. Så hvis programmet støtter dato, datetime2 og datetimeoffset jeg sterkt råd om å bruke de nye datetime datatyper siden de har knapt noen ulempe.

Takk for din tid. For flere interessante artikler besøk http://www.dirtyread.de/

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.