Data MySQL o ora PHP?

Question

Di solito memorizzo le date come numeri interi usando la funzione PHP time() in un database MySQL piuttosto che usare il formato data di MySQL semplicemente perché è più facile da manipolare quando lo rimando, ma ci sono degli svantaggi?

Answer 1

Gamma:

C'è sempre lo svantaggio evidente: la gamma che è possibile memorizzare è limitata A partire da 1970 al 2038. Se è necessario memorizzare le date di fuori di questo intervallo, sarà in genere necessario utilizzare un altro formato. Il caso più comune che ho trovato in cui questo si applica è alla data di nascita.

Leggibilità:

Penso che la ragione più importante che la gente ha scelto di utilizzare uno dei data-tipi built-in esso che i dati è più facile da interpretare. Puoi fare una semplice selezione e comprendere i valori senza dover formattare ulteriormente la risposta.

rilevamenti:

una buona ragione tecnica per utilizzare il tipo di data è che permette di interrogazione indicizzata in alcuni casi timestamp unix non. Si consideri la seguente query:

SELECT * FROM tbl WHERE year(mydate_field) = 2009; 

Se mydate_field è di un tipo di data nativa, e c'è un indice sul campo, questa query sarà effettivamente utilizzare un indice, nonostante la chiamata di funzione. Questo è praticamente l'unico momento 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 pensate un po ', c'è un modo intorno ad esso, però. Questa query fa la stessa cosa, e sarà in grado di utilizzare le ottimizzazioni di indice:

SELECT * FROM tbl WHERE mytimestamp_field > unix_timestamp("2009-01-01") AND mytimestamp_field < unix_timestamp("2010-01-01"); 

Calcoli:

In generale, ho memorizzare le date come tempo di Unix, nonostante gli svantaggi. Questo non è realmente basato sui suoi meriti, ma piuttosto perché mi sono abituato. Ho scoperto che questo semplifica alcuni calcoli, ma complica gli 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 in realtà semplifica i calcoli. Ad esempio, è abbastanza comune che tu voglia selezionare i post, diciamo, negli 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 io personalmente trovo più veloce e più facile che dover rember la sintassi di una funzione come DATE_SUB().

Timezones:

timestamp Unix non può memorizzare i dati di fuso orario. Vivo in Svezia con un fuso orario unico, quindi non è un problema per me. Tuttavia, può essere un grave problema se si vive in un paese che si estende su più fusi orari.

Answer 2

Ho usato per fare lo stesso, ma ora lo memorizzo come MySQL DateTime - semplicemente perché ciò significa che quando si guardano i dati grezzi nel database posso interpretarlo facilmente.

Oltre a questo, è probabilmente più semplice lavorare con i dati con altri linguaggi che non utilizzano in modo eccessivo il timestamp UNIX (come fa PHP), ma in ogni caso non c'è una grossa spinta.

Answer 3

Uno svantaggio è che non sarà possibile manipolare e interrogare quelle date utilizzando le funzioni SQL.

Answer 4

che non è troppo male, ma sarete perdendo un po 'costruito in funzionalità come:

select * from table1 dove dateColumn = getDate() - 30

Usa datetime se potete!

Answer 5

Solo un paio a cui riesco a pensare:
* Se un'altra applicazione non php deve utilizzare il database, questo sarà in un formato difficile da leggere.
* Se si desidera eseguire qualsiasi lavoro basato su SQL in queste date (ad esempio aggiungendo un mese o ottenendo tutti i valori per un anno specifico, ecc.), Ciò sarà più difficile.

Answer 6

Una leggera perdita di dettagli. La variabile Datetime di MySQL può essere molto precisa.

Inoltre, se devi confrontare le date nel tuo database, il formato della data ha alcune funzioni integrate che non sarai in grado di utilizzare.

Answer 7

Il timestamp UNIX presenta ovvi limiti all'intervallo di date che è possibile memorizzare.

Inoltre, utilizzo sempre i campi DATETIME ora. Puoi fare un sacco di calcoli matematici con DATE utilizzando SQL in modo da poter estrarre informazioni utili come DATEDIFF tra ora e una data memorizzata senza utilizzare alcun PHP.

Answer 8

ci sono molti svantaggi:

• mancanza di precisione; Il tempo Unix è preciso solo al secondo e solo per le date tra 1901-12-13 e 2038-01-19 quando si utilizza il tipico numero intero a 32 bit
• Non è possibile utilizzare alcuna funzione di database incorporato per interrogare o manipolare i dati
• non è possibile memorizzare un fuso orario

Se avete bisogno di un time_t, è abbastanza facile da convertire a uno in codice.

Answer 9

È possibile definire una clausola di aggiornamento automatico per i timestamp di MySQL nella definizione della tabella.
http://dev.mysql.com/doc/refman/5.0/en/timestamp.html

Answer 10

Penso che per motivi di scalabilità è preferibile utilizzare i timestamp Unix.

Vantaggi:

• sempre memorizzati in UTC fuso orario (se si dispone di server su più fusi orari conversione non necessaria).
• Le applicazioni li convertono nel fuso orario preferito (ciò si verifica solo una volta, all'ultimo livello possibile).
• Non stringhe (quelle sono enormi rispetto ai numeri interi).
• Calcoli meno database (roba come created < 19345345345-24 * 60 * 60 viene calcolato una volta).

EDIT: MySQL Timestamps non vengono memorizzati internamente come stringhe, ma quando ha tirato fuori il database coloro vengono convertiti in stringhe. Il tipo DATETIME non viene modificato da MySQL, il che significa che se si inserisce una data nel database si ottiene lo stesso.

Se si dispone di visitatori su un sito Web da un fuso orario diverso, è necessario convertire le date come stringa-> stringa anziché integer-> stringa). In alcuni paesi le date non sono solo numeri (per esempio in Francia è Mardi 15 mai 2012, preferisco farlo in PHP o JS. Penso che un intero di conversione di simpe-> stringa sia più veloce di Integer-> String-> String. Plus nessuna mal di testa se la migrazione a server in un altro paese

falsi svantaggi:..

• credo che la gamma limitata di Unix timestamp non sia effettivamente limitato un time-stamp è un numero intero nel database, in modo da poter regolare le dimensioni. Per impostazione predefinita, un numero intero unsigned è int(10), quindi è possibile memorizzare numeri fino a 4294967295, ma i propri limiti non sono fissi in modo che possiamo facilmente cambiare int(10) int a int(16) bigint