SQL Server Datetime vs. Datetime2

er zijn veel tijd-en datumformaten in SQL Server met verschillende bereiken, nauwkeurigheid, opslaggroottes en door de gebruiker gedefinieerde fractionele seconde-precisies.

Hieronder volgt een kort overzicht:

we willen ons concentreren op de vergelijking van DateTime en datetime 2 formaat. In mijn huidige bedrijf kom ik veel oudere tabellen tegen die datetime gebruiken. Datetime2 werd voor het eerst geïntroduceerd in SQL Server 2008. Ik denk echter dat sommige ontwikkelaars gewoon niet weten over de voor-en nadelen van datetime2.

Datetime

laten we eerst een beetje bespreken datetime. Zoals u hierboven kunt zien, heeft het 8 bytes opslag nodig en heeft het een bereik van 1753-01-01 tot 9999-12-31. Met name heeft het een korte afstand naar achteren. Dit komt omdat Groot-Brittannië in 1752 van de Juliaanse naar Gregoriaanse kalender verhuisde door een paar dagen over te slaan. Om precies te zijn, 2 September 1752 werd gevolgd door 14 September 1752. Omdat een datum voor 1753 dubbelzinnig zou zijn, is het datetime-type niet geldig voor 1753. Een andere opvallende eigenschap van het datetime datatype is de nauwkeurigheid van 0,00333 seconden, dat is in feite 1/300 van een seconde.

dit lijkt een beetje vreemd. We hebben geen milliseconde nauwkeurigheid met datetime. Oké, maar waarom? Laten we het DateTime datatype grondig analyseren. In een datetime gebruiken we 4 bytes voor datum en 4 bytes voor tijd. Hoe werkt dat precies? Laten we eens kijken.

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

dus 0x0000A55F00A4CB80 is hexadecimaal. Laten we de 8 bytes in twee stukken scheiden. Eerst de date. 0x0000A55F staat voor de datum. In decimaal is het 42335. Dat is het aantal dagen verstreken sinds 1900-01-01. Bewijs:

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

nu voor de tijd dat we de laatste 4 bytes 0xA4CB80 vertaald naar decimaal is het 10800000. Dat betekent 10800000 teken vanaf middernacht. Weet je nog dat ik zei dat de nauwkeurigheid 1/300 van een seconde is? Dat is te wijten aan het feit dat datetime slaat de tijd in teken. Dus 10800000 teken sinds middernacht betekent 10800000 keer 1/300 van een seconde. Laten we een beetje berekenen.

dus we hebben precies 10 uur vanaf middernacht en dat vertaalt zich perfect naar 10: 00: 00. Gecombineerd met de datum hebben we 2015-11-29 10: 00: 00.

onthoud dat datetime altijd 8 bytes opslag gebruikt en houd ook in gedachten dat de eerste vier bytes die de datum vertegenwoordigen negatief kunnen zijn (2complement) omdat de datum vóór 1900 kan zijn. Bijvoorbeeld, in 1890-11-29 krijg je de eerste 4 bytes als 0xFFFFF308, wat zich vertaalt als 32-bit 2-aanvulling op -3320. En 3320 gesubstitueerd van 1900-01-01 is precies 1890-11-29.

datetime2

Alle datum en tijd datatypes die geà ntroduceerd zijn met SQL Server 2008 hebben een volledig nieuw opslagtype dat we nu zullen onderzoeken. Het datetime2 datatype gebruikt 6 tot 8 bytes afhankelijk van de miliseconde precisie.

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

deze keer wordt het iets ingewikkelder. In alle nieuwe datetime datatypes staan de laatste drie bytes voor de datum. Dat is te wijten aan een verandering van byte volgorde. Dus datetime wordt opgeslagen als little endian, wat betekent dat de meest significante byte op de meest linkse terwijl in big endian de meest significante byte op de meest rechtse positie wordt opgeslagen.

dat betekent dat wanneer we 0x0300512502BA3A0B nemen de datum niet 0xBA3A0B maar 0x0B3ABA is, aangezien één byte 2 hexadecimale cijfers is.

nogmaals met de wiskunde: 0x0B3ABA staat voor de decimale 735930. Dit is precies de datum die we wilden.:

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

nu de bytes geconverteerd zijn kunnen we gewoon de laatste bytes van little endian representation nemen die 0x0225510003 is. Houd er rekening mee dat de allerlaatste byte in little endian (dat is de eerste byte in original big endian) de opgegeven precisie is. Zoals je kunt zien hebben we datetime2(3) gedefinieerd, wat betekent dat onze allerlaatste byte 0x03 is.

de wiskunde uitvoeren: 0x02255100 staat in decimaal 36000000. Omdat we precisie 3 hebben gebruikt, wat 3-cijferige precisie betekent, berekenen we eerst de seconden door ons getal met 10 te delen tot de kracht van precisie die in ons geval 103 is.

dit vertaalt zich ook perfect naar 10 uur 0 minuten 0 seconden, zoals gezegd.

datetime vs DateTime 2

eindelijk een eenvoudige en duidelijke vergelijking tussen deze twee datatypes.

datum en tijd datetime2 –
max precieze oneven precisie van 1/300 100 nanoseconde precisie
gebruiker gedefinieerd precisie geen ja, variërend van 0 tot 7
opslagruimte altijd 8 bytes 6 – 8 bytes, afhankelijk van de precisie
bruikbaar met + of – operator ja nee, gebruik datediff, dateadd enz.
SQL Standard compatible Nee Ja

dus over het algemeen zie je dat datetime potentieel meer opslagruimte gebruikt, een lagere en oneven precisie heeft, een lager bereik heeft en niet compatibel is met de SQL-standaard, waardoor je code zich anders gedraagt op verschillende DBMS. Dus als uw applicatie ondersteunt datum, DateTime 2 en datetime offset ik sterk adviseren over het gebruik van de nieuwe datetime datatypes omdat ze nauwelijks enig nadeel.

Bedankt voor uw tijd. Voor meer interessante artikelen Bezoek http://www.dirtyread.de/

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.