Oren Eini, também conhecido como Ayende Rahien, recomenda aos desenvolvedores a evitar remoções lógicas deixando o leitor com a impressão que remoções físicas são uma opção. Em resposta ao post, Udi Dahan diz que é altamente recomendado evitar ao máximo a remoção de dados.
Os defensores da remoção lógica sugerem o acréscimo da coluna Removido à tabela de forma a deixar os dados intactos. Um registro será considerado removido se o flag Removido estiver habilitado. Ayende considera essa abordagem "simples, fácil de entender, rápida de implementar e explicar" mas "frequentemente, errada". O problema é que:
a remoção de uma linha ou uma entidade raramente é simples. A operação afeta não somente os dados do modelo mas também a sua forma. É por isso que utilizamos chaves estrangeiras, para garantir que os itens de uma OrdemDeCompra não fiquem sem uma OrdemDeCompra associada. E esse é o caso mais simples. …
Quando trabalhamos com remoções lógicas, é fácil chegar em situações onde temos dados corrompidos já que a UltimaOrdem de um Cliente (uma simples otimização) poderá apontar para uma OrdemDeCompra que foi removida logicamente.
Se um desenvolvedor é solicitado a remover informações de uma base de dados, e se a remoção lógica não é recomendada, então sobra apenas a remoção física. Para preservar a integridade dos dados, ele deverá remover o registro e todos os registros associados automaticamente. Udi Dahan chama a atenção para o fato de que o mundo real não funciona assim:
Digamos que nosso departamento de marketing decide remover um Produto do catálogo. Devemos então remover todas as Ordens de Compra que contém esse Produto? Devemos também remover todas as Faturas relacionadas a essas ordens? Indo mais além, devemos recalcular os lucros da empresa?
Que ninguém deixe ele fazer isso.
O problema está na interpretação de uma "remoção". Dahan mostra o seguinte exemplo:
Na verdade, 'remover’' um Produto significa que ele será descontinuado. Nós não queremos mais vender essa linha de Produtos. Nós queremos nos livrar do estoque que temos e nunca mais comprar de nosso fornecedor. O produto não deverá aparecer em pesquisas de usuários, mas o pessoal do almoxarifado ainda tem que gerenciar esses itens. De qualquer forma é muito mais fácil dizer apenas 'remover'.
E ele continua dando a interpretação correta do usuário:
Ordens de compra não são removidas - elas são canceladas. Pode haver inclusive a incidência de alguma taxa se a ordem for cancelada muito tarde.
Colaboradores não são removidos - eles são demitidos (ou se aposentam). A rescisão também poderá ser tratada no sistema.
Vagas não são removidas - elas são preenchidas.
Em todos os casos devemos focar na tarefa que o usuário deseja executar ao invés da ação técnica que deverá ser executada em uma entidade. Em quase todas as situações, mais de uma entidade será levada em consideração.
Ao invés de utilizar a flag Removido, Dahan sugere a utilização de um campo com o estado das informações: ativo, descontinuado, cancelado, demitido, etc. Esse campo permite que o usuário analise os dados do passado e tome alguma decisão.
Remover informações também podem ter outras conseqüências negativas além de violar a integridade referencial. A recomendação de Dahan é deixar os dados no banco: "Não remova. Simplesmente não remova."