[MySql] Tenere traccia delle cancellazioni

[serialkiller]

Originariamente inviato da optime
stiamo tutti e due parlando a livello di codice, giusto? o tu intendi a livello applicativo?

altra domanda: l'applicativo è scritto in ...?

Si, codice, per togliere dubbi, l'applicativo è mio, ed è scritto in php

[optime]

allora, se la cosa è centralizzata non ci sono problemi. fai precedere la DELETE dall'inserimento nelle tabelle "_canc" dei record che stai per cancellare.

[serialkiller]

Originariamente inviato da optime
allora, se la cosa è centralizzata non ci sono problemi. fai precedere la DELETE dall'inserimento nelle tabelle "_canc" dei record che stai per cancellare.

Si per questo non è un problema, la mia domanda era principalmente rivolta alla corretta logica della cosa, nel senso, esistono modi più rapidi o più efficaci che dir si voglia, voi come vi comportereste, è la strada giusta insomma...

[deleted_29]

in tal caso, come detto, non ti consiglio di tenere una o più tabelle "ombra", bensì una tabella log.

Dove scrivi chi sta facendo cosa, da quale punto del programma, in quale momento, che informazioni altera.

rende mooolto più semplice, in fase di rendicontazione, capire esattamente che succede

tipo

"utente=ABC;tabella=clienti;azione=cliente=005240; impostato emailscadenze a superantani@virgilio.it da supercazzola@tin.it;"

Nel sorgente, materialmente, ci sono istruzioni del tipo

RegistraLog(tabella,azione,cosa);
eseguiquerysql(...faqualcosa...);

dove registralog compila anche tante altre belle cose
(data, ora, utente loggato etc.etc, comandosql eseguito, rigadatabase modificata)

Non funziona bene per operazioni massive, tipo
delete from clienti, mentre va bene operazioni "a riga"
delete from clienti where codicecliente=123

io, almeno, faccio così

[optime]

io addirittura loggo lo statement sql

[deleted_29]

Originariamente inviato da optime
io addirittura loggo lo statement sql

stato editando.
pure io, e se è a riga singola anche la riga prima (per fare il rollback)

[serialkiller]

Originariamente inviato da franzauker
in tal caso, come detto, non ti consiglio di tenere una o più tabelle "ombra", bensì una tabella log.

Dove scrivi chi sta facendo cosa, da quale punto del programma, in quale momento, che informazioni altera.

rende mooolto più semplice, in fase di rendicontazione, capire esattamente che succede

tipo

"utente=ABC;tabella=clienti;azione=cliente=005240; impostato emailscadenze a superantani@virgilio.it da supercazzola@tin.it;"

io, almeno, faccio così

Spiegami meglio perfavore, tieni conto che oltre a tenere conto di chi fa cosa, dovei avere la possibilità di fare un restore in caso di errore di qualche idiota.
Da quel che ho capito tu dici, fai una tabella log con tot campi per es: id_utente,tabella,id_tabella,data_ora,ecc,ecc, ad ogni operazione segue o precede l'insert nella tabella log con i vari dati, se ho capito bene, così non ho modo di fare un restore degli eventuali dati cancellati per "errore".

[serialkiller]

Originariamente inviato da franzauker
Non funziona bene per operazioni massive, tipo
delete from clienti, mentre va bene operazioni "a riga"
delete from clienti where codicecliente=123

Ecco, come dicevo nel primo post, di operazioni massive c'è ne sono, un esempio tra tuti, tabella evento madre relazionata alla tabella sottoeventi relazionata alla tabella giornate sottoeventi, questo implica che se viene cancellato un evento madre, di conseguenza vengono cancellati i suoi sottoeventi (che possono anche essere 200/300) e le giornate ad essi abbinati (che possono essere 500/1000)

[optime]

qui le cose che vuoi ottenere sono 2:

1. log delle operazioni

2. possibilità di restore

giusto?

[serialkiller]

Originariamente inviato da optime
qui le cose che vuoi ottenere sono 2:

1. log delle operazioni

2. possibilità di restore

giusto?

Esatto