Excluir registro ou ocultar

[rockrgo 138]

Bom dia pessoal,

 

estou com algumas dúvidas sobre exclusão de registros. A alguns dias vi um post de um moderador dizendo que não é correto excluir registros em uma aplicação...então fiquei na dúvida a respeito.

 

tenho uma aplicação onde o cliente gostaria de excluir um usuário mas gostaria de manter o processo referente ao usuário. Nesse caso se excluísse o usuário o processo perderia a referência e na verdade nem daria para excluir pois iria dar erro da chave estrangeira.

 

Se eu só ocultar a exibição do usuário para o cliente e ficar acumulando registros no banco de dados, vou perder muita performance nas consultas? Realmente não é uma boa prática remover registros, ou depende da necessidade?

 

Valeu galera, aguardo as opiniões.

[Motta 645]

Em alguns casos não é bom excluir pois se perde a informação, o que se faz no caso é tratar isto em um campo de tipo "status" o registro está mas na prática o sistema não o lê , a desvantagem disto é o trabalho maior pois TODAS AS QUERIES tem de ter algo como :

SELECT *
FROM TABELA
WHERE DELETEADO <>'SIM'

Note que este DELETEADO difere de uma situação de negócio do tipo :

Contrato Cancelado

Pedido Cancelado

Funcionário Demitido

Etc

 

Pessoalmente não gosto deste tipo de solução, mas em alguns casos ela é válida.

[Prog 183]

Trabalho muito com data... Exemplo, dataRemovido ou dataDesativado (timestamp).

 

É totalmente pertinente saber que, todos os registro que possuem esta data em nulo, não foram removidos.

 

Consulta não devem ser executadas em tabelas, mas sim no indice. Caso suas consultas não estiverem utilizando indices, você deve rever seu modelo e também suas consuLtas.

 

O moderador que citou o erro ao excluir os dados fui eu. Eu não quis dizer que é necessariamente errado eliminar os dados, mas como você mesmo já percebeu, seus dados históricos perdem referência, logo, deixam de fazer sentido.

 

Se você possui uma base de dados que cresce demasiadamente, há outras estratégias para solucionar esta questão.

Se a estratégia for excluir, simplesmente, há claramente uma falha de analise e/ou planejamento de negócio.

[Fernando C 128]

dizendo que não é correto excluir registros em uma aplicação

na verdade, não é nem questão de "correto"...

é sempre bom lembrar que em algumas aplicações profissionais (talvez várias)

1 empresa é obrigada por lei a manter registros durante anos..

v. legislação de imposto de renda, INSS, NF-e (sobre especificamente NF-non capisco niente mas INSS me parece que são 30 anos...)...

 

há 1 materia mt interessante na SQL Magazine sobre manter históricos..

acho q do ano passado..

se não me engano, o foco da matéria era partição de tabelas,

mas o Ricardo Rezende utiliza esse exemplo (criação de tabelas "histórico").

para demonstrar q vc pode manter 1 histórico durante anos sem sobrecarregar tabelas atuais com dados que vc só utilizaria raramente.

 

Estou no serviço agora.

A noite eu chego em casa e pesquiso que nº é e retorno s/ compromisso..

 

[Motta 645]

o Protheus da Totvs por exemplo não deleta registros , invés disto marca uma coluna que existe em toda tabela padrão chamada D_E_L_E_T_ com um *, o registro não existe para o Sistema mas está no BD, para deletar fisicamente é preciso entrar num módulo á parte ou no gerenciador do BD.

Tem horas em que isto é útil pois a informação pode ser recuperada, mas torna as queries mais complexas por exemplo.

[rockrgo 138]

Estou entendendo pessoal!

 

Realmente Prog acho que o post foi seu sim.....na verdade não quis dizer errado literalmente, mas sim em questão de boa prática e regra de negócio.

 

Não entendi a parte de que as consultas devem ser realizadas nos índices e não em tabela? Como assim? Tem algum material bom para leitura que possa indicar?

 

Obrigado.

[Prog 183]

Na prática, você executa suas consultas em tabelas, porém, internamente não é isto o que ocorre. Suas pesquisas são submetidas ao servidor e um "analisador de consulta" (otimizador) procura qual o "melhor caminho" para chegar aos resultados desejados, os melhores caminhos são os indices. Sim, eventualmente se você não possuir indices ou se o analizador não conseguir encontrar um caminho mais "rápido", o analizador vai optar por fazer um table full scan.

 

Se você tiver uma consulta com 2 campos como filtros e um indice com esses mesmos campos, por exemplo, provavelmente o otimizador vai optar por utilizar o indice para selecionar os registros ao invez de realizar uma consulta diretamente na tabela.

 

É isso.

Uma leitura mais técnica e detalhada pode ser obtida aqui:

http://cdn.oreillystatic.com/en/assets/1/event/21/Understanding%20and%20Control%20of%20MySQL%20Query%20Optimizer_%20Traditional%20and%20Novel%20Tools%20and%20Techniques%20Presentation.pdf

[Motta 645]

Complementando o Prog, índices e as estatísticas de Banco atualizadas.

[Fernando C 128]

sobre particionamento, caso alguem se interesse:
http://www.devmedia.com.br/particionamento-no-oracle-revista-sql-magazine-105-parte-1/26326
http://www.devmedia.com.br/particionamento-no-oracle-parte-2-revista-sql-magazine-106/26717
http://www.devmedia.com.br/particionamento-de-dados-no-sql-server-revista-sql-magazine-106/26713

no mysql:
http://www.devmedia.com.br/utilizando-o-mysql-partitioning-sql-magazine-75/16825
http://www.devmedia.com.br/utilizando-o-mysql-partitioning-parte-2-sql-magazine-76/17190