2015-07-06 17 views
5

Attualmente ho un DB MySQL non temporale e ho bisogno di cambiarlo in un DB MySQL temporale. In altre parole, devo essere in grado di conservare una cronologia delle modifiche apportate a un record nel tempo a fini di reporting.Come implementare i dati temporali in MySQL

Il mio primo pensiero per l'implementazione di questo è stato semplicemente inserire gli inserti nelle tabelle anziché gli aggiornamenti e quando ho bisogno di selezionare i dati, semplicemente facendo un GROUP BY su alcune colonne e ordinando il timestamp DESC.

Tuttavia, dopo aver riflettuto un po 'su le cose, ho capito che sarebbe davvero un guaio perché la chiave primaria per ogni inserto (che in realtà si limiterebbe a simulare un numero di aggiornamenti su un singolo record) sarà diversa e quindi rovinare qualsiasi collegamento che utilizza la chiave primaria per collegarsi ad altri record nel DB.

Come tale, il mio prossimo pensiero è stato quello di continuare ad aggiornare le tabelle principali nel DB, ma anche di creare un nuovo inserto in una "tabella di controllo" che è semplicemente una copia del record completo dopo l'aggiornamento, e quindi quando I necessario per riferire sui dati temporali, potrei usare la tabella di controllo per scopi di interrogazione.

Qualcuno può darmi qualche consiglio o link su come farlo correttamente?
Grazie.

+1

Una soluzione tipica è creare una nuova tabella di controllo e scriverla automaticamente utilizzando un trigger. I metodi includono la duplicazione dello stato completo della riga o semplicemente [il rilevamento di quale campo è stato modificato] (http://stackoverflow.com/questions/779230/using-mysql-triggers-to-log-all-table-changes-to-a- secondaria tabella). – AndySavage

+3

Dr. Richard Snodgrass ha un libro fantastico su questo argomento, disponibile qui. http://www.cs.arizona.edu/~rts/publications.html Forse più informazioni di quante speravate, ma ancora materiale di A-list. –

+0

Grazie ad entrambi. Questo è quello che stavo cercando. Inoltre, Ollie, nella pagina che hai collegato, ci sono diversi libri elencati. Sai quale in particolare dovrei guardare? Grazie. – HartleySan

risposta

3

Rendere la data tabella R temporale (ovvero, per mantenere la cronologia).

Un motivo è di lasciare la tabella R così com'è e creare una nuova tabella R_Hist con valid_start_time e valid_end_time. Il tempo valido è il momento in cui il fatto è vero.

Le operazioni CRUD può essere somministrato come:

INSERTO

  • inserto in entrambe R
  • Inserire in R_Hist con valid_end_time come infinito

UPDATE

012.
  • Aggiornamento in R
  • INSERT INTO R_Hist con valid_end_time come infinito
  • Aggiornamento valid_end_time con l'ora attuale per il “ultimo” tupla

DELETE

  • Elimina dal R
  • Aggiornamento valid_end_time con l'ora corrente per " ultima”tuple

SELEZIONA

  • Selezionare R per le query 'snapshot' (implicitamente 'ultima' timestamp)
  • Selezionare R_Hist per le operazioni temporali

Invece, puoi scegliere di progettare una nuova tabella per ogni attributo della tabella R. Con questo particolare disegno puoi acquisire dati temporali a livello di attributo rispetto al livello di entità in il disegno precedente. Le operazioni CRUD sono quasi simili.

+0

Questa è la conclusione di base alla quale sono arrivato.Avere due tavoli è l'approccio migliore, sono d'accordo. Grazie. – HartleySan

Problemi correlati