Quando memorizzare Data / DataTime?

0

Sto lavorando su un sito web di social network e non sono abbastanza sicuro quando dovrei memorizzare data / datetime. Il servizio include alcuni dei seguenti eventi:

  • Registrati / Login
  • Segui
  • "Mi piace" (immagini e commenti)
  • Pubblica un commento
  • Pubblica un'immagine

Ai miei occhi, userei DateTime per tutti loro ... Anche se non sono sicuro che sia professionale o forse è solo uno spreco di spazio.

Quando dovrei memorizzare l'orario di un evento? Grazie in anticipo.

    
posta Shahar 02.02.2014 - 19:27
fonte

4 risposte

1

Per tutte le cose che hai menzionato, memorizzerei una data / ora perché sono cose che effettivamente sono avvenute in un dato momento e puoi facilmente catturare quell'ora automaticamente.

Catturare il tempo ti offre una maggiore flessibilità rispetto alla semplice acquisizione di una data. Ad esempio, è possibile mostrare all'utente il Tempo per le cose accadute nelle ultime 0-48 ore e regolare l'ora per il fuso orario locale. Per cose accadute più tempo fa puoi scegliere di mostrare loro la data anche se stai memorizzando tutto il tempo. Per cose come login, probabilmente non mostrerò mai all'utente il tempo in cui si sono registrati, ma non c'è motivo valido per non avere quel dato.

Tendo a memorizzare le date per le cose che il tempo non è necessario e / o gli utenti devono inserire manualmente perché l'inserimento dei tempi richiede più tempo e la metà delle volte si avranno comunque ipotesi.

    
risposta data 02.02.2014 - 19:48
fonte
0

Non memorizzare necessariamente un Datetime per tutti questi. Tuttavia nella maggior parte dei casi sembra essere una buona idea. Ecco la mia logica:

  • Registrati / Accedi: è un gioco da ragazzi per archiviarlo, qui. Basti pensare ai ticket di supporto relativi agli account compromessi o al caso in cui blocchi l'account di qualcuno? Dovresti essere in grado di dire a un cliente quando è successo.
  • A seguito, Mi piace: per me non c'è una buona ragione che renderebbe necessario memorizzarlo. Questi campi sono basati sull'interesse personale e, a meno che tu non stia pianificando statistiche su questi campi che richiedono tempo, puoi lasciarlo andare, qui. Direi che queste sono solo metainformazioni. Segue la metainformazione per un account e gli piace la metainformazione per un post.
  • Pubblicare commenti / immagini comunque sono informazioni reali. La prospettiva che l'utente ha nei confronti di queste informazioni cambierà nel tempo. Nessun utente commenta un anno "È il mio compleanno, oggi" dopo un anno e auguro loro un buon compleanno. Anche se dopo questo lungo periodo di tempo l'ora esatta di più potrebbe non avere più importanza per questo post, potrebbe, per altri post. Quindi memorizzare logicamente un datetime mi sembra importante, qui.
risposta data 02.02.2014 - 20:11
fonte
0

Stai registrando il momento nel tempo in cui si è verificata un'azione dell'utente. Questo è comunemente chiamato un timestamp. Sfortunatamente, la memorizzazione dei timestamp nei database è più complicata di quanto la maggior parte delle persone realizzi e la soluzione corretta dipende dalla particolare implementazione del database che si sta utilizzando.

Si desidera registrare il momento in cui si è verificato un evento, in questo caso un'azione dell'utente. Ci sono due modi comuni per rappresentare un momento nel tempo: come un fuso orario locale insieme a un fuso orario compensato dal Tempo medio di Greenwich, o come un numero di secondi (o millisecondi o nanosecondi) da qualche momento nel passato ( inizio di epoca ). Sfortunatamente, generalmente nessun tipo di SQL supporta uno di questi. I tipi DATE e DATETIME non registrano un fuso orario e pochi database hanno qualsiasi tipo rappresentato come "time since start of epoch". Lo standard SQL definisce un tipo "TIMESTAMP WITH TIMEZONE" ma pochi database popolari lo supportano.

La maggior parte degli sviluppatori si compromette usando DATETIME con un certo fuso orario implicito. Se lo fai, dovrai stare attento a registrare tutte le volte nello stesso fuso orario. L'unico che ha senso è registrare tutti i tempi in GMT. Impostare il fuso orario del server predefinito su GMT e impostare il fuso orario del database su GMT, se applicabile. Devi essere molto attento a convertire correttamente i tipi di dati delle applicazioni nel fuso orario corretto prima di registrarli nel database.

In alternativa, puoi registrare i timestamp come offset numerico da qualche punto nel passato. Il sistema Unix e le sue derivate e il runtime Java rappresentano il tempo in secondi dal 1970-01-01 alle 00:00 GMT. Se lo fai, potresti voler definire le viste che convertono queste in una rappresentazione leggibile.

    
risposta data 02.02.2014 - 22:16
fonte
0

Regola empirica generale quando si parla del proprio archivio dati principale; tendono a memorizzare più informazioni piuttosto che meno.

Ci sono buone ragioni per cui potresti voler conoscere una data e un amp; tempo per tutti quegli eventi, come altri hanno sottolineato. Se non ora, poi più tardi.

In tutti i casi specifici elencati, memorizzerei una data e un'ora.

E davvero, l'aggiunta di un campo data e ora dovrebbe avere solo un piccolo impatto sulle prestazioni. Se stai facendo un INSERIMENTO comunque, qual è un campo in più? Puoi avviare le prestazioni di micro-optomising in un secondo momento, se necessario.

    
risposta data 03.02.2014 - 09:08
fonte

Leggi altre domande sui tag