Memorizzazione di statistiche su periodi di tempo e fusi orari più lunghi

Question

Attualmente sto lavorando a un progetto che calcola i dati e li memorizza per ID in un database di analisi.

Ad esempio la quantità di volte in cui un articolo di notizie viene letto (e quindi ci sono come 20 categorie di dati memorizzati come numero intero).

Noi memorizzare i dati in campi come segue: int id_utente int value_type_id int valore datetime datetime

Usiamo 4 tavoli, x_hour, x_day, x_week, x_month In questo modo non avremo a calcolare i dati su un potenziale di poche migliaia o addirittura milioni di record.

I dati devono essere calcolati al volo e filtrati da determinati join. Questo non è un problema e funziona come previsto e ad una velocità che è soddisfacente.

Il problema che segue. Vogliamo che i dati vengano visualizzati nel fuso orario dell'utente che li visualizza, il fuso orario non è sempre lo stesso poiché può essere utile, ad esempio UTC-5 o UTC + 4.

Poiché archiviamo le date in UTC, abbiamo problemi con intervalli su giorni, settimane e mesi poiché se l'attività è archiviata un'ora prima di mezzanotte, gli intervalli più grandi la vedranno come ieri, anche se potrebbe essere lo stesso giorno in quel fuso orario.

Ho letto soluzioni aggiungendo 24 colonne per contenere i dati per ogni fuso orario, qualcuno ha una soluzione diversa.

Answer 1

Sembra che l'unica strada da percorrere sia l'utilizzo di bucket di 15 minuti, o di fusi orari definiti in modo preciso, che otterrebbero solo circa 40 colonne.

Quindi abbiamo fatto lo stesso per giorni settimane e mesi in modo che abbiamo dati corretti per ogni fuso orario.

Un po 'più di tempo e più spazio per l'archiviazione dei dati, ma se manteniamo puliti i nostri dati potrebbe essere una soluzione abbastanza decente.

Answer 2

Continua a memorizzare i dati in UTC.

Passare il fuso orario dell'utente alla query.

Converti in SELECT, utilizzando la funzione CONVERT_TZ:

CONVERT_TZ(`datetimefield`, 'UTC', 'Europe/Amsterdam') 

Dove 'Europe/Amsterdam' viene sostituito con il fuso orario appropriato.

È meglio utilizzare le stringhe del fuso orario IANA come sopra, anziché scostamenti come "UTC-5", a condizione che questi dati siano disponibili. Gestirà correttamente i problemi relativi all'ora legale nelle regioni in cui ciò avviene.

Ulteriori note: https://dev.mysql.com/doc/refman/5.5/en/mysql-tzinfo-to-sql.html - Questo programma è utilizzato per intializzare MySQL con i dati del fuso orario.