2010-03-29 24 views
19

Devo creare un codice in PHP che mi consenta di mantenere la cronologia degli aggiornamenti dei record nel database MySQL in modo da poter trovare per data una vecchia revisione.Come mantenere la cronologia degli aggiornamenti dei record in MySQL?

Ecco l'esempio di quello che voglio actualy achive: http://en.wikipedia.org/w/index.php?title=Tunisia&action=history

I dati sono per lo più i numeri che registriamo circa l'azienda per generare report e per estrarre indici.

Ho intenzione di utilizzare il codeigner per la sua semplicità e sto cercando un'idea su un framework o un progetto opensource che utilizzi lo stesso approccio per mantenere la cronologia delle modifiche nel database.

risposta

1

Non sta registrando gli aggiornamenti SQL effettivi. Sta registrando gli aggiornamenti dei dati. In effetti, memorizzerà ogni revisione della pagina e fornirà solo l'ultima per impostazione predefinita. Il codice SQL che è stato utilizzato per questo non è stato memorizzato.

Quindi dovrete adottare un approccio simile. Ogni volta che i dati cambiano, dovrai capire come sono cambiati i dati e archiviare questi dati 'patch'. Probabilmente starai meglio conservando l'ultima versione, piuttosto che dover lavorare su tutte le patch per arrivarci. Ciò significa che sarete in grado di vedere qualcosa di simile

! created file 
* added data to cell D4 'product descript' D5 'set of pens' E5 '£5.99' 
* added data to cell D6 'toaster' E5 '£10' 
& changed data in cell D4 'Product Description' 

Ognuno di questi cambiamenti avrebbe bisogno di essere archiviati con un timbro di tempo o quando Dove fatto. Dovrai anche elaborare il tuo schema per memorizzare le modifiche ai dati.

Un'altra soluzione più semplice, sarebbe quella di utilizzare un motore wiki, che fornisce tutte le funzionalità che si desidera, se si è disposti a lavorare in una pagina web. Potrebbe essere necessario passare un po 'di tempo per farlo funzionare meglio per le tue esigenze, lasciando che le persone lo modifichino da una vista più completa, piuttosto che una wiki grezza.

2

È necessario utilizzare un livello aggiuntivo tra l'applicazione e il db. Puoi fare una semplice da sola (invece di chiamare direttamente lo mysql_query chiami una funzione fatta da te che la avvolge e che tiene traccia degli aggiornamenti), o usa un ORM esistente. In pseudo-codice

my_mysql_query($query){ 
    if($query is an update){ 
     //Log stuff before query 
    } 
    $r = mysql_query($query); 

    if ($r && $query is an update){ 
     //Log stuff after query 
    } 
    return $r; 
} 

E poi nella vostra applicazione che si chiamano my_mysql_query invece di mysql_query. È possibile verificare se la tabella è quella che si desidera tracciare e copiare la riga in una copia della tabella originale.

Se si utilizza Doctrine ORM, è possibile utilizzare il suo Event Listeners per ottenere ciò che si desidera.

7

Un modo semplice per mantenere la cronologia delle versioni consiste nel creare fondamentalmente una tabella identica (ad esempio con il suffisso _version). Entrambe le tabelle avranno un campo versione, che per la tabella principale si incrementa per ogni aggiornamento eseguito. La tabella delle versioni avrebbe una chiave primaria composita su (id, version).

Ogni volta che si esegue un aggiornamento sulla tabella effettiva, si inserisce anche una nuova riga nella tabella delle versioni con dati duplicati. Ogni volta che vuoi trovare la cronologia delle versioni, tutto ciò che devi fare è qualcosa come SELECT * FROM content_version WHERE id = CONTENT_ID ORDER BY version.

Se si utilizza qualcosa come Doctrine ORM, ha un comportamento che lo fa automaticamente per gli ascoltatori di eventi.Puoi verificarlo qui: http://www.doctrine-project.org/documentation/manual/1_2/en/behaviors#core-behaviors:versionable

+5

perché non andare così: 'tabella principale' contiene solo' id' e 'version_id'' versione' tabella contiene tutti i dati? – Shaheer

+0

Grazie @Shaheer Vado a provare questo. – Eric

+0

@Shaheer perché la maggior parte delle query è in contrasto con i dati correnti, quindi suddividere la cronologia su una tabella separata assicura che tali query non ottengano la penalizzazione delle prestazioni per il fatto che la tabella diventi * n * volte più grande. Quanto grande * n * dipenderà dalla frequenza con cui i record vengono aggiornati. –

1

Se ho capito bene, stai salvando solo un "numero" in una tabella specifica e vuoi la cronologia delle revisioni di quel numero?

Direi: scrivi la tua datamodel in modo che contenga una cronologia di quel numero. In questo modo non solo registri l'ultimo valore di quel numero ma anche i valori precedenti.

Un modo semplice per farlo è di avere una tabella con i seguenti campi:

  • id
  • CompanyID
  • numero
  • timestamp

Se vuoi sapere il numero attuale, basta fare

SELECT * FROM table WHERE companyId = X ORDER BY timestamp DESC LIMIT 1 

Se volete vedere tutte le revisioni solo fare:

SELECT * FROM table WHERE companyId = X 
+0

È un dashboard che sto cercando di migrare da un semplice file di Excel. Dato che non ho familiarità con il modo ORM, preferisco scrivere il mio codice. – Proxium

+0

Quale può essere una buona cosa :) –

+1

SELECT * FROM table WHERE companyId = X ORDER BY timestamp DESC LIMIT 1 – DarkSide

15

La soluzione più semplice (a seconda delle esigenze specifiche) sarebbe probabilmente aggiungere un on aggiornamento/inserimento/cancellazione di innesco al vostro tavolo, in modo da può eseguire la registrazione aggiuntiva quando i dati sono inseriti/aggiornati/cancellati. In questo modo verranno trattati anche gli interventi manuali sul db ...

Verificare http://dev.mysql.com/doc/refman/5.1/en/triggers.html per ulteriori informazioni.

6

Esiste un framework open source (licenza MIT) per creare il tipo CRM ed ERP di applicazioni Web basate su database. È possibile scaricare EPESI da anche http://epe.si/ accessibile SourceFroge: http://sourceforge.net/projects/epesi/

di EPESI CRUD motore - il Record Browser - ha una storia disco molto efficiente, così come altre caratteristiche come il sistema di autorizzazione avanzata (fino a un campo livello) e molto altro.

Un singolo recordset memorizza i dati in un massimo di 10 tabelle ed è indipendente dal database (utilizza PHPAdoDB). Una tabella chiamata recordset_data memorizza i dati "grezzi" e la storia dei cambiamenti vengono memorizzati in 2 tabelle aggiuntive: recordset_edit_history e recordset_edit_history_data.edit_history

di record ha la seguente struttura:

  • ID (chiave primaria per questa tabella, indice)
  • Redatta il (timestamp: 2008-05-14 15:18:15)
  • Edited da: (user ID) edit_history_data

di record ha la seguente struttura:

  • edit_id = ID dalla cronologia
  • campo = il nome del campo che è stato cambiato
  • old_value = valore del campo che ha cambiato.

È un motore molto veloce ed efficiente e memorizza le modifiche non sul record ma su un singolo livello di campo.

Problemi correlati