Ajuda para criação de uma lixeira no sistema

leandroleo:

Ola pessoal,

Gostaria de uma idéia:

Digamos que eu tenha um sistema e que eu não queira que nenhuma informaçao seja excluída em definitivo, que sempre que o cara excluir vá para uma lixeira.

Eis a questão: Esta lixeira poderia ser uma flag que marcasse a tupla no proprio banco como lixeira. ex: 0 - lixeira, 1- visivel por exemplo.
ou para cara tabela criada, duplicar essa tabela pra comportar apenas ítens excluídos.

o que vcs achão, alguem tem alguma idéia melhor pra me ajudar.

Sistemas de Informação de verdade nunca apagam (delete) nada. A sua ideia é muito válida.
Uma entidade pode ser removida. Isto signifca que ele não mais existe para efeitos do negocio. É o que se chama de remoção lógica.
Colocar a flag de removed true/false é o suficiente. Indexe esse campo e sempre coloque where removed = false nas suas queries.

Se vc tem auditoria vc precisa gravar um lançamento que diga que o registro foi removido.

Associado à flag de removido existem 3 operações:

1. estornar - torna o registro visivel de novo
2. deletar - fisicamente remove o registro - por exemplo depois que o registro foi colocado num data wharehouse.
3. expurgar - fisicamente apagar todos os registros com flag de removido - por exemplo, para poupar espaço.

Existem algumas detalhes não obvios e não triviais. Se A tem filhos B ao remover A, precisa remover B. Se vc fizer o delete ha um efeitos castada (cascade) mas sem isso, vc tem que simular essa cascada na mão setando os flags de B na mão (se bem que pode usar um update para mudar todos de ma vez). o detalhe aqui é ter que explicitamente sabem quem são os filhos. Isto pode não ser trivial.

Vlw sergio. vc parece ser um cara muito inteligente.

brigadoo.

Uma dica para que vc não precise escrever em todas as suas queries o ‘where deleted = false’ é vc criar um view que faça isso pra vc =D
Assim vc não corre o perigo de esquecer em uma única query do sistema inteiro, e ferrar com a lógica de tudo.

Outra coisa. Lembre-se que para que isso funcione, você não pode ter índices únicos no seu BD. É o preço que se paga.

Caso contrário, vamos supor que um cliente se cadastre com o e-mail [email removido] . Depois de um tempo, o cadastro dele é apagado. Se o e-mail for único, ao tentar criar um novo cadastro, também com [email removido], ele não conseguirá. O banco reporta um alerta de índice duplicado (já que, para o banco, efetivamente existe lá uma linha com esse valor, marcada com deleted=true).

E, para quem vê o sistema, não existe um usuário com aquele e-mail.

Blz vinygodoy bem lembrado vlw.

ViniGodoy:

Outra coisa. Lembre-se que para que isso funcione, você não pode ter índices únicos no seu BD. É o preço que se paga.

Caso contrário, vamos supor que um cliente se cadastre com o e-mail [email removido] . Depois de um tempo, o cadastro dele é apagado. Se o e-mail for único, ao tentar criar um novo cadastro, também com [email removido], ele não conseguirá. O banco reporta um alerta de índice duplicado (já que, para o banco, efetivamente existe lá uma linha com esse valor, marcada com deleted=true).

E, para quem vê o sistema, não existe um usuário com aquele e-mail.

Vc pode usar isso como mecanismo de estorno. Ou seja, vc está na realidade usando um cadastro que foi apagado antes. Nada melhor que trazê-lo da lixeira e usá-lo. ( ou pelo menos sugerir isso ao usuário).

Isso só pode ser feito se o campo em questão identificar o mesmo usuário. Era o caso do exemplo que eu dei, mas pode não ser o caso sempre.

clone_zealot:

Uma dica para que vc não precise escrever em todas as suas queries o ‘where deleted = false’ é vc criar um view que faça isso pra vc =D
Assim vc não corre o perigo de esquecer em uma única query do sistema inteiro, e ferrar com a lógica de tudo.

Outra opção é passar todos os registros com essa flag para outra tabela, ou para um sistema histórico. Isso evita de ficar com registros que nunca mais serão usados numa tabela de trabalho, melhorando as pesquisas e performance geral do sistema, mas só pode ser feito se não houver dependência alguma desses dados.

Particionamento é outra coisa a pensar também.

Bruno Laturner:

clone_zealot:

Uma dica para que vc não precise escrever em todas as suas queries o ‘where deleted = false’ é vc criar um view que faça isso pra vc =D
Assim vc não corre o perigo de esquecer em uma única query do sistema inteiro, e ferrar com a lógica de tudo.

Outra opção é passar todos os registros com essa flag para outra tabela, ou para um sistema histórico. Isso evita de ficar com registros que nunca mais serão usados numa tabela de trabalho, melhorando as pesquisas e performance geral do sistema, mas só pode ser feito se não houver dependência alguma desses dados.

Particionamento é outra coisa a pensar também.

Isso é equivalente a não colocar flag alguma e simplesmente copiar o registro para outra tabela quando ele é removido. Essa foi a segunda opção referida pelo autor do topico. Sim, resolve o problema dos repetidos e pode aumentar a performance,mas quebra o modelo OO que é uma beleza… sim, é um modelo melhor para o banco, mas pior para OO.

É o tipo trade-off O-R. Como eu prefiro O a R minhas tabelas são apenas dados, toda a logica de controle está no java. Mas para quem prefrir o R essa opção de copia é melhor.

(se estamos preocupados com a performance porque copiar e guardar os dados que não usaremos ?)

Que tal Hibernate Envers? Alguém já usou? Ele seguiria o principio de copiar dados para uma nova tabela… Porém de uma maneira bem mais fácil.

Alguma opinião positiva? ou negativa?