SQL Server memorizza DATETIMEinternamente come due INTvalori, come spiega SQLDenis .
È corretto (per estensione logica) che i DATEtipi (SQL Server 2008+) siano archiviati come singoli INT ?
SQL Server memorizza DATETIMEinternamente come due INTvalori, come spiega SQLDenis .
È corretto (per estensione logica) che i DATEtipi (SQL Server 2008+) siano archiviati come singoli INT ?
Risposte:
Solo per divertimento, vediamo cosa c'è nella pagina.
CREATE DATABASE floob;
GO
USE floob;
GO
CREATE TABLE dbo.experiment(d DATE NOT NULL);
CREATE CLUSTERED INDEX x ON dbo.experiment(d);
INSERT dbo.experiment SELECT SYSDATETIME();
DBCC IND('floob', 'dbo.experiment', 1);
Risultati parziali (differiranno un po 'sul tuo sistema):
----
13
PagePID iam_chain_type PageType
------- -------------- --------
229 In-row data 10
228 In-row data 1
Quindi diamo un'occhiata a pagina 228:
DBCC TRACEON(3604, -1);
DBCC PAGE(13, 1, 228, 3);
Risultati parziali. Vediamo che il valore per d occupa 3 byte. Se osserviamo il dump della memoria per la riga, vediamo un valore esadecimale per il componente di archiviazione interno: c8350b02- che cosa potrebbe essere?

SELECT DATEDIFF(DAY, CONVERT(DATE, '0001-01-01'), CONVERT(DATE, '2012-06-11'));
Risultato:
734664
Così:
SELECT CONVERT(VARBINARY(8), 734664);
Risultato:
0x000B35C8
(Sembra incredibilmente simile a quello che c'è sulla pagina, solo con i bit capovolti nell'ordine opposto?)
Poi:
SELECT DATEADD(DAY, CONVERT(INT, 0x000B35C8), CONVERT(DATE, '0001-01-01'))
Risultato:
2012-06-11
datechi non ha una parte temporale.