Ci sono buoni motivi per mantenere la data e l'ora in colonne separate?

Sto cercando di capire la decisione del nostro fornitore di software di mantenere la data e l'ora in colonne separate. Ad esempio, quando la riga è stata creata o aggiornata. Sia l'ora che la data sono colonne DateTime. Stiamo usando SQL Server 2005.

Il database contiene i dati del nostro sistema ERP e credo che le tabelle più grandi contengano circa 3 milioni di righe. La maggior parte delle tabelle è approssimativamente compresa tra 100000 e 1 000 000 di righe.

Personalmente sceglierei di default un singolo DateTime per un singolo timestamp. Ciò consentirebbe calcoli della differenza oraria più semplici e la data e l'ora potrebbero essere facilmente estratte dal timestamp. Consumerebbe anche meno spazio.

La separazione di data e ora è una cattiva pratica o c'è qualcosa di molto brillante in questo progetto che non capisco?

La mia ipotesi è che sia una cosa di supporto legacy (cioè nella versione 1 del loro software, avevano data e ora in campi separati e sono stati costretti a supportarlo perché ha sempre funzionato in quel modo).

Detto questo, non c'è niente di geniale nel separare data e ora, quindi non c'è nulla che ti manchi.

(L'altra opzione è che gli sviluppatori del sistema ERP non sapevano che un campo data / ora può memorizzare una data e un'ora, ma è molto più probabile che abbiano un requisito aziendale per farlo funzionare come nelle versioni precedenti.)

In generale, dipende dall'uso. Se molte query stanno unendo sotto-elementi insieme, considera invece di archiviarli insieme e poi prendi il sopravvento nel doverli dividere in quelle occasioni più rare. Certo, la divisione a volte è più complessa (o impossibile): considera un person_full_nameattributo da cui devi estrarre person_family_name. Detto questo, buttare giù un valore temporale è banale, quindi generalmente preferirei memorizzare la data e l'ora insieme.

Considera anche di archiviare insieme E separatamente, con vincoli (e forse trigger) per assicurarti che non vadano fuori sincrono: in questo modo assumi il colpo di divisione / unione al momento dell'aggiornamento piuttosto che al momento della query del dati.

Non riesco a vedere molto utile per questo in un sistema operativo. In un sistema analitico potresti volere una dimensione data separata con una granulosità di "giorni", quindi la data si collega ai report di rollup della data e forse una colonna "ora" se vuoi fare analisi per ora del giorno per qualche motivo .

È inoltre possibile presentare la data e l'ora come colonne calcolate in base a una colonna data / ora principale.

Per aggiungere al commento di ConcernedOfTunbridgeWe, esiste un vantaggio in termini di prestazioni della query se si dispone di una tabella DateDimension e TimeDimension. Considera che la tabella dei fatti ha sia dateDimensionKey che TimeDimensionKey. Se vuoi trovare il numero di qualcosa tra le 8:00 e le 17:00, puoi semplicemente farlo

SELECT COUNT(1) FROM FactTable f Inner Join TimeDimension t on f.TimeDimensionKey = t.TimeDimension WHERE t.Hour BETWEEN 8 AND 17.

Se hai aggiunto un indice a TimeDimensionKey, dovrai solo cercare un indice per il risultato sulla tabella dei fatti per cercare i dati

Senza la tabella TimeDimension, dovrai fare qualcosa di simile al seguente,

SELECT COUNT(1) FROM FactTable f WHERE DatePart(mintue, f.Date) BETWEEN 8 AND 17

Ciò richiederà probabilmente una scansione della tabella perché il motore di database deve calcolare il risultato per ogni riga prima di poter capire quali dati possono essere restituiti.