Gamma:
C'è sempre l'ovvio svantaggio:l'intervallo che puoi memorizzare è limitato dal 1970 al 2038. Se devi archiviare date al di fuori di questo intervallo, generalmente dovrai utilizzare un altro formato. Il caso più comune che ho trovato in cui questo si applica riguarda le date di nascita.
Leggibilità:
Penso che il motivo più importante per cui le persone hanno scelto di utilizzare uno dei tipi di data incorporati è che i dati sono più facili da interpretare. Puoi fare una semplice selezione e comprendere i valori senza dover formattare ulteriormente la risposta.
Indici:
Un buon motivo tecnico per utilizzare i tipi di data è che consente la query indicizzata in alcuni casi che i timestamp unix non lo fanno. Considera la seguente query:
SELECT * FROM tbl WHERE year(mydate_field) = 2009;
Se mydate_field è di un tipo di data nativo e nel campo è presente un indice, questa query utilizzerà effettivamente un indice, nonostante la chiamata alla funzione. Questa è praticamente l'unica volta in cui mysql può ottimizzare le chiamate di funzione su campi come questo. La query corrispondente su un campo timestamp non sarà in grado di utilizzare gli indici:
SELECT * FROM tbl WHERE year(from_unixtime(mytimestamp_field)) = 2009;
Se ci pensi un po', però, c'è un modo per aggirarlo. Questa query fa la stessa cosa e lo farà essere in grado di utilizzare le ottimizzazioni dell'indice:
SELECT * FROM tbl WHERE mytimestamp_field > unix_timestamp("2009-01-01") AND mytimestamp_field < unix_timestamp("2010-01-01");
Calcoli:
In genere, memorizzo le date come ora Unix, nonostante gli svantaggi. Questo non è davvero basato sui suoi meriti, ma piuttosto è perché ci sono abituato. Ho scoperto che questo semplifica alcuni calcoli, ma ne complica altri. Ad esempio, è molto difficile aggiungere un mese a un timestamp unix poiché il numero di secondi al mese varia. Questo è molto semplice usando la funzione mysql DATE_ADD(). Tuttavia, penso che nella maggior parte dei casi semplifichi effettivamente i calcoli. Ad esempio, è abbastanza comune che tu voglia selezionare i post, diciamo, dagli ultimi due giorni. Se il campo contiene un timestamp unix, questo può essere fatto facilmente semplicemente facendo:
SELECT * FROM tbl WHERE mytimestamp_field > time() - 2*24*3600;
Probabilmente è una questione di gusti, ma personalmente lo trovo più veloce e più facile che dover ricordare la sintassi di una funzione come DATE_SUB().
Fusi orari:
I timestamp Unix non possono archiviare i dati del fuso orario. Vivo in Svezia che ha un unico fuso orario, quindi questo non è davvero un problema per me. Tuttavia, può essere un grosso problema se vivi in un paese che copre più fusi orari.
