In un database, useresti un campo data o campi anno e mese se ti servono solo l'anno e il mese?

Question

Sto allestendo un tavolo dove mi servono l'anno e il mese. In MySQL credo di avere 2 opzioni: (1) 2 campi: 1 per anno, 1 per mese o (2) un campo data (il giorno sarebbe sempre 1).

I 2 campi ha il vantaggio di essere un po 'più veloce (credo) perché MySQL non deve convertire il valore da una data a un intero sebbene questo sia probabilmente trascurabile. Il campo data ha il vantaggio della convalida "automatica": qualcuno non può ottenere dati nel db con il mese 13 o l'anno 1. Con un campo data puoi anche fare calcoli più facilmente (es.).

Quale useresti? O c'è un altro che useresti?

Answer 1

Utilizzare un campo data. Poiché sql supporta i campi data nativamente, è facile filtrare per date specifiche usando la clausola WHERE.

I 2 campi ha il vantaggio di essere un po 'di ciò che più veloce [...]

vostra query SELECT non è il collo di bottiglia, quindi non dovreste preoccuparvi di questo. La leggibilità e un programma pragmatico sono più importanti di un "collo di bottiglia percepito".

Answer 2

Se si eseguono molte operazioni nel campo della data, lo divideremo in colonne separate e gestirò la convalida dei dati in un vincolo di tabella o nel DAL.

Ad esempio, la creazione di rapporti di vendita per giorno, mese, anno è molto più efficiente quando i campi vengono suddivisi. Il motivo è che non è necessario utilizzare le funzioni datetime per dividere la data per il raggruppamento.

Se si tratta di qualcosa come un compleanno in cui potrei interrogarlo di tanto in tanto, non me ne preoccuperei e lo lascio in un campo data.

Answer 3

Vorrei utilizzare il campo della data anche se è necessario solo l'anno e il mese in cui non si perde nulla raccogliendo tutti i dati. Come pratica standard, raccolgo sempre tutti i dati quando è possibile.

Answer 4

Probabilmente non perché il più piccolo tipo di dati datetime in SQL Server (Microsoft) è smalldatetime lungo 4 byte. Se hai bisogno solo di mese e anno, allora hai bisogno di 1 byte per il mese e 2 byte per anno.

Answer 5

Vorrei utilizzare colonne separate, principalmente perché ciò consentirebbe un migliore utilizzo degli indici. Ad esempio, non penso che un indice su una colonna datetime ti aiuterà se sei solo interessato ai dati di un dato mese (non all'anno).

Answer 6

Anche se non immediatamente utile a voi, IBM Informix Dynamic Server supporta il tipo:

DATETIME YEAR TO MONTH 

Questo memorizza esattamente quello che vuoi - l'anno e il mese. Ha i suoi usi. La famiglia di tipi DATETIME include molti altri tipi che occasionalmente hanno i loro usi - e alcuni che sono di utilità marginale, l'esempio canonico è DATETIME MONTH TO MINUTE. (Lo svantaggio del tipo sono le notazioni prolisse necessarie per manipolarlo, ma ci sono molte operazioni che possono essere eseguite su qualsiasi o tutti i tipi DATETIME.)

In molti DBMS, è possibile posizionare vincoli sulle colonne, quindi se si utilizza un approccio a due colonne, si posizionerà un vincolo CHECK(month_column BETWEEN 1 AND 12) sulla colonna per garantire che l'utente non abbia inserito un valore non valido nella tabella.Potresti anche applicare un vincolo alla colonna dell'anno.

Inoltre, alcuni DBMS consentono di creare tipi definiti dall'utente, e un tipo di anno-mese è piuttosto semplice come questi andare. I dettagli dipendono dal DBMS, ovviamente.

Answer 7

A meno che non vi sia uno specifico vantaggio in termini di prestazioni di memorizzare l'anno e il mese separatamente, vorrei attenermi alla data. Per quanto riguarda l'indicizzazione, se hai due colonne, dovrai creare un indice sulla combinazione di colonne anziché su una colonna di date. La data verrà convertita internamente in un valore lungo in modo che lo spazio di archiviazione richiesto non sia realmente un problema.

Inoltre, pensate al possibile dolore di manutenzione con due campi. Avresti due campi db, forse due campi su un oggetto o la necessità di costruire/analizzare il mese e l'anno da/verso il db. Resta semplice con una data e lascia che il DB tenga traccia della tua integrità dei dati.

Lavoro con i dati come descritto - date di scadenza in cui il giorno è sempre l'ultimo giorno del mese, quindi abbiamo solo bisogno di mese e anno. Noi li conserviamo come una data.

Answer 8

Manterrei una colonna datetime e due colonne calcolate con mese e anno (indicizzate ovviamente). Avere la mia torta e mangiarla troppo :)

Answer 9

Se si anticipano le query del modulo "dammi tutte le righe a luglio, indipendentemente dall'anno", sarà un po 'più facile scrivere con colonne separate per mese e anno. Un indice separato per la colonna del mese dovrebbe renderlo scattante.

Altrimenti, sceglierei la singola colonna della data: convalida semplice, comprensibile, incorporata e funzioni matematiche della data. La tua unica preoccupazione è che qualcuno di nuovo al design si chiederà perché tutto si verifica sempre il primo del mese.

C'è un altro motivo per utilizzare colonne del mese e dell'anno separate in cui sono incappato: quando il mese non è noto. L'ho usato per le app che consentono a un evento imminente di essere "nel 2009". In tal caso, l'utilizzo di un valore NULL nella colonna del mese risolve il problema in modo corretto. Non esiste un modo semplice per farlo con una colonna di tipo data, a meno che non si presenti un attacco orribile come il 2 gennaio, il mese è sconosciuto.

Answer 10

Pensateci in questo modo: un giorno qualcuno verrà da voi con l'obbligo di migliorare l'applicazione con la possibilità non solo di salvare anno e mese, ma anche un giorno. Vuoi aggiungere una colonna in più per un giorno? E poi, dopo, potrebbero volere che tu risparmi anche il tempo.

Quanto sarebbe facile migliorare la funzionalità se si dispone di colonne separate per anno/mese/giorno? Se hai una singola colonna della data?

Vorrei andare per una colonna di date solo per questo motivo.