2009-03-30 16 views
31

Devo inserire un anno (es .: 1988, 1990 ecc.) In un database. Quando ho utilizzato il tipo di dati Date o Datetime , si stanno verificando degli errori. Quale tipo di dati dovrei usare.SQL DataType - Come conservare un anno?

risposta

24

Se hai bisogno di memorizzare un anno nel database, vorresti usare un tipo di dati Integer (se sei morto solo su memorizzazione dell'anno) o un tipo di dati DateTime (che implicherebbe la memorizzazione di una data che in pratica è 1/1/1990 00:00:00 in formato).

+7

** Non essere pigro e "usa solo int". ** Misura il tuo tipo di dati correttamente, un int due byte è una scelta migliore.Memorizzando 4 cifre in 4 byte, stai sprecando più risorse del solo spazio su disco. Il tuo sistema sarà sempre appesantito usando due volte la memoria cache, spingendo due volte la quantità di dati IO, ecc. Per questa colonna. Non è un gioco da ragazzi, vedi: http://dba.stackexchange.com/q/4968 –

0

Solo un anno, nient'altro? Perché non usare un numero intero semplice?

+0

Ohh dio ,, Per buon senso – peter

+4

Hey! Perché stai cercando di rendere le cose così semplici? Finiremo le domande SO! –

1

Utilizzare l'intero se tutto ciò che è necessario memorizzare è l'anno. Puoi anche usare datetime se pensi che ci saranno calcoli basati sulla data mentre stai interrogando questa colonna

+0

grazie ,, questo è il mio errore – peter

25

regolare 4 byte INT è la strada verso il grande, è uno spreco di spazio!

Non si dice quale database si sta utilizzando, quindi non posso raccomandare un tipo di dati specifico. Tutti dicono "use integer", ma la maggior parte dei database memorizza numeri interi a 4 byte, il che è molto più del necessario. È necessario utilizzare un numero intero a due byte (smallint su SQL Server), che consente di risparmiare spazio.

+1

Molto spesso, sprecare spazio usando un int è preferibile usare un tipo di dati più piccolo, poiché la maggior parte dei processori moderni è più efficiente nell'elaborazione 4 byte inte (32 bit) rispetto ai tipi di dati più piccoli. – Ender

+0

@Ender, non stai davvero facendo matematica con questi valori, è più un processo di archiviazione e ricerca. Sarai in grado di memorizzare più valori nella ram se sono più piccoli, sarai in grado di leggere più valori dal disco se sono più piccoli, ecc. Non sono riuscito a trovare articoli che supportano la tua idea. http://dba.stackexchange.com/q/4968 –

+1

Tutti i programmi vengono compilati al codice macchina alla fine e i numeri vengono caricati nei registri. Nelle moderne architetture CPU tutti i registri sono a 32 bit o 64 bit. Quindi il tuo sistema RDBMS dovrà mettere quei numeri in registri per fare un confronto al fine di soddisfare le condizioni della tua query. E nel caso di tiny int e small int, deve effettuare una conversione ogni volta, che richiede molto tempo. Non riesci a trovare un articolo UFFICIALE che supporti il ​​mio punto O il tuo punto dal momento che di solito è un compromesso tra CPU e IO poiché l'uso di int aumenterà la dimensione dell'indice e richiederà più IO – Ender

9

Ehi, è possibile utilizzare anno() tipo di dati in MySQL È disponibile in formato a due o quattro cifre.

Nota: I valori consentiti in formato a quattro cifre: 1901 al 2155. I valori consentiti in formato a due cifre: da 70 a 69, che rappresentano anni 1970-2069

2

Memorizzazione di un "Anno" in MSSQL idealmente dipenderà su cosa stai facendo con esso e quale sarebbe il significato di quell'anno per la tua applicazione e il tuo database. Detto questo, ci sono alcune cose da dire qui. Non esiste "DataType" per Anno a partire dal 2012 in MSSQL. Mi piacerebbe usare SMALLINT perché è solo 2 byte (risparmiando 2 dei 4 byte richiesti da INT). La tua limitazione è che non puoi avere un anno più vecchio di 32767 (a partire da SQL Server 2008R2). Davvero non penso che SQL sarà il database di scelta tra diecimila anni, per non parlare di 32767. Si può considerare INT come la funzione Year() in MSSQL converte il tipo di dati "DATE" in un INT. Come ho detto, dipende da dove stai ricevendo i dati e dove sta andando, ma SMALLINT dovrebbe andare bene. INT sarebbe eccessivo ... a meno che tu non abbia altri motivi come quello che ho menzionato sopra o se i requisiti del codice lo richiedano in formato INT (ad esempio l'integrazione con l'applicazione esistente). Molto probabilmente SMALLINT dovrebbe andare bene.

0

L'archiviazione può essere solo una parte del problema. Come verrà utilizzato questo valore in una query?

Sarà confrontato con un altro tipo di dati data-ora o tutte le righe associate avranno anche valori numerici?

Come gestiresti una modifica dei requisiti? Con quale facilità potresti reagire a una richiesta di sostituzione dell'anno con una minore fascia temporale? cioè ora lo vogliono suddiviso per quarti?

Un tipo numerico può essere facilmente utilizzato in una query di data ora disponendo di una tabella di ricerca in cui inserire elementi come le date di inizio e fine (1/1/X a 12/31/x), ecc.

Problemi correlati