Form php e traccia modifica dati

[Tulipan0nero]

Ciao ragazzi,
cercavo un'idea su come realizzare una certa cosa: ho un database mysql con diversi utenti i cui dati vengono visualizzati su di un'apposita pagina php contenente un bel form con tanti campi (nome, cognome, sesso,età, domicilio).
Ogni utilizzatore può richiamare liberamente i dati di ogni utente e modificarli premendo poi sul pulsante apposito di aggiornamento che non fa altro che fare un update del record sulla tabella del db.
Fin qua mi pare semplice e chiaro.
Ma mi è stato chiesto questo: c'è un modo per vedere QUALI sono state le modifiche effettuate ai dati utente? E da chi?
La seconda richiesta è di facile realizzazione, no problem.
Ma la prima?
Mi hanno suggerito: quando fai l'update si crea in coda alla pagina una sorta di copia della situazione precedente alla modifica.....ma mi pare assurda come cosa.
Mi è stato anche suggerito: puoi scrivere in rosso il testo che è stato modificato in modo tale che si capisca COSA è stato modificato?
Queste soluzioni però non mi convincono...ne tantomeno posso andare a duplicare il record utente creandone uno gemello.
Come diamine faccio? Mi sto scervellando ma non trovo una soluzione....

Qualche idea?

Ciao

Tulipano

[Tulipan0nero]

Dovrei creare una sorta di pulsante TIMEMACHINE o REWIND che mi faccia vedere le versioni precedenti alla modifica...ma come?

[Tulipan0nero]

Ho provato a caricare il vecchio record su di una tabella di appoggio..ma non va. Qualche idea?

[eiyen]

Questo problema è noto nella "teoria" dei db... che dbms usi? MySQL?

Cmq le soluzioni per te potrebbero essere:
- backup dei record (prima di ogni aggiornamento memorizzi i dati vecchi): questo lo puoi fare creando un campo aggiuntivo "revisione" per ogni recordo da "backuppare" e quando recuperi i dati sai che quello "effettivo" ha il numero di revisione più alto, p.es. - se hai una sola tabella da gestire è molto semplice. Alternativamente puoi fare una tabella separata tipo "backup" con campi "tabella, campo, valore, revisione" in cui memorizzi le revisioni "passate" riportando il nome della tabella, del campo, il valore precedente e un numero di revisione (questa è più flessibile come soluzione)
- storico delle azioni: puoi registrare non i dati ma le azioni di aggiornamento... in pratica memorizzi le query di UPDATE: memorizzando proprio la stringa SQL o - meglio - le sue info, magari in una tabella a parte che può contenere o la stinga SQL direttamente oppure campi come "tabella, elencocampi, elencovalori" o simile...

[Tulipan0nero]

Ciao Eiyen,
pensavo anche io al concetto di record duplicato...
Quando faccio una insert sulla tabella utenti del mio record viene creata una insert gemella su di una tabella uguale che ha un campo ID_RECORD che è uguale al campo ID della tabella originale ed una campo revisione che è un progressivo.
Avrò quindi la tabella PIPPO con il record con ID=1 ad esempio e la tabella PIPPO_BCK con il record ID_REV=1 e ID_REC=1, ID_REV=2 e ID_REC=1, ID_REV=3 e ID_REC=1.
In questo modo per il record con ID=1 avrò memorizzato nella mia tabella di backup tre revisioni diverse corrispondenti a tre modifiche effettuate nel tempo.
In alto nella pagina che visualizza il form posso mettere un pulsantino di "rewind" che mi visualizza le varie revisioni a partire dalla più recente.

Mi pare che come logica sia quello che mi hai suggerito....non sembra difficilissimo da implementare. L'unico problema è che avrò un TABELLONE enorme di backup dato che ad ogni update della tabella madre viene fatta invece una insert nella tabella BACKUP!!!!

Dammi conferma che il mio ragionamento fila.

Grazie

Tulipano

[eiyen]

sì... in linea di massima è così e va bene... d'altronde se vuoi registrare tutte le "variazioni" devi per forza tenere tutto nel db... per "snellire" la tabella puoi fare come ti suggerivo... anzichè registrare l'intero record potresti memorizzare il nome del campo variato ed il nome del valore: se si cambia solo un campo avrai comunque un record aggiuntivo, ma la tabella è più piccola... se però cambi molti campi avrai molti record aggiuntivi... in conclusione mi pare ti convenga fare come grosso modo dicevi (quanti campi hanno questi record?)

[Tulipan0nero]

PURTROPPO sono record con più di 100 campi....mi viene da piangere! :-)
Cmq è la via più semplice replicare l'intero record....in caso contrario dovrei fare prima un controllo su COSA è stato modificato e fare l'insert solo delle modifiche...ma è un casino in più che vorrei evitarmi.

[eiyen]

mmmh... allora forse la mia idea potrebbe andar bene... diciamo che dipende anche dalla mole delle variazioni... se però non è insolito cambiare pochi campi (magari uno solo) ad ogni variazioni può andar bene.
Se ad esempio l'utente cambia i campi "A" da "a1" ad "a2" e "B" da "b1" a "b2" nella tabella di backup con campi REF (l'id di riferimento nella tabella principale, quindi una chiave esterna) CAMPO, VALORE, REVISIONE e ID autoincrementante avresti qualcosa come:

ID	REF		CAMPO		VALORE	REVISIONE
800	100		A			a1		3
801	100		B			b1		3

per recuperare i dati del record #100 fai una select filtrando in base a REF=100 e alla revisione, p.es. la numero "3":

SELECT * FROM backup WHERE (REF=100 AND REVISIONE<=3) ORDER BY CAMPO asc, REVISIONE desc

Se in una revisione NON compaiono campi (e capiterebbe spesso), allora devi tornare indietro con lo storico a quelle precedenti: in pratica per ogni campo selezioni la revisione più alta disponibile (nell'esempio sopra per un ipotetico campo "C" selezioni il record di backup con revisione più alta <=3, ecco il motivo di tale confronto): dalla SELECT di cui sopra dovresti prendere il primo record che compare per ogni campo... quelli che ancora mancassero vuol dire che non sono mai stati modificati.


Si complica il "recupero" dei dati, ma si semplifica l'inserimento degli stessi.

[Tulipan0nero]

Troppo complicato per uno alle prima armi come me!
Preferisco fare una bella insert alla tabella PIPPO_BCK ogni volta che faccio un UPDATE della tabella originaria.

Piuttosto: la sintassi del link che devo mettere in alto sulla pagina per tornare alle release precedenti....
Pensavo di creare una pagina ad hoc backup.php perchè voglio cambiare il layout grafico facendolo come in bianco e nero.

In alto alla pagina form.php mettero un link del tipo:

backup.php?ID=$ID
(sto facendo un esempio)
Come mi otterrei quel valore:
Select max (id) from PIPPO_BCK WHERE ID_RECORD=3 (che è l'ID del record che sta sulla tabella madre PIPPO).
In questo modo mi tirerei fuori il link che punta alla release più aggiornata (che è quella con ID più grande.....).
Passerei quindi in POST alla pagina backup.php il valore di ID perchè mi serve per creare il link che su quella pagina poi mi servirebbe ad ottenermi le release più vecchie.

Sulla pagina backup.php farei così:
$ID_NEW=$GET(ID)-1 (gli sto dicendo che il nuovo valore di ID adesso gli sarà dato dal valore di $ID che gli ho passato in post dalla pagina main.php diminuito di 1).
Così il link per tornare indietro alla release precedente da dentro la pagina backup.php sarà nuovamente : backup.php?ID=$ID_NEW

Spero di aver fatto capire LONTANAMENTE quello che vorrei fare!
Dovrebbe funzionare!


Tulipano

[eiyen]

Va bene... fai un INSERT totale allora (ma se non vuoi provare soluzioni alternative a priori non porti neanche il problema...): dovresti secondo me però inserire un "numero di revisione" e non basarti sull'id interno (tra l'altro gli ID di uno stesso record potrebbero - quasi sempre sarà così - NON essere consecutivi se sono state fatte nel frattempo modifiche ad altri record)... in pratica nella tabella "originale" potresti aggiungere un campo con il numero di revisione attuale (partendo da 1) e quando fai un update lo incrementi dopo aver copiato l'intero record (inclusa la revisione) sulla tabella di backup.

Per lo storico basta prendere dai backup il valore più alto della revisione che è quello attuale-1 e per "navigare" nello storico vai avanti/indietro con tale valore.