Registros "excluídos" em cascata que não são realmente excluídos

Apenas tentando ter algumas idéias sobre o que as pessoas fazem para esse cenário. Temos um banco de dados do sistema (SQL Server 2008 R2) que possui tabelas e cada tabela possui um campo que podemos chamar de "Excluídos". Basicamente, é um campo de bits se for um 1 o registro for excluído, se for um 0, não será excluído. O campo não é anulável e seu padrão é obviamente 0.

Não podemos permitir exclusões reais no banco de dados; portanto, para contornar isso, definimos um campo de bit (Excluído) como true. Em nossa aplicação, terminamos com consultas parecidas com esta:

SELECT blah FROM MyTable WHERE .. AND Deleted=0

Basicamente, filtramos os registros para obter apenas linhas não excluídas. Nosso problema está nos registros relacionados que precisam ser conectados em cascata. O que as pessoas preferem, deveríamos fazer isso no código do servidor para que, quando você exclua um registro, ele exclua (Define o campo de bit excluído como true) para todos os registros relacionados? Ou isso deve ser um gatilho que deve verificar esse campo e definir o campo de bit para todos os registros relacionados como 1?

Ou estamos completamente no caminho errado?

Não há boa solução aqui. Os bancos de dados oferecem exclusão em cascata eficiente e especial por meio de chaves estrangeiras, mas se, como você diz, a exclusão real não for uma opção, não será possível tirar proveito dessa cascata nativa.

Dependendo se as exclusões são comuns ou raras, será mais eficiente emular a cascata imediatamente (por meio de consultas ou gatilhos extras) quando você pseudo-excluir algo, ou apenas para sempre buscar tudo no banco de dados e filtrar a exclusão sinalizador na lógica de negócios.

Pessoalmente, sempre usei uma terceira opção: todos os registros subsidiários são acessíveis apenas a partir do registro mestre, o que nunca acontece se esse for excluído com suavidade; portanto, você não precisa fazer nada! Obviamente, isso só funciona se o seu modelo de dados for uma árvore estrita (os comentários são recuperados apenas ao visualizar o produto ao qual se aplicam, os privilégios do usuário são recuperados apenas ao administrar o usuário ao qual pertencem etc.) em vez de uma Web (onde você pode consultar todos os comentários ou todos os registros de privilégios com indiferença), mas acho que isso pode funcionar para surpreendentemente muitos cenários.

Já fiz isso antes com tabelas de auditoria, nas quais todas as alterações em um banco de dados são gravadas em uma tabela de espelho de auditoria (Inserir / Atualizar / Excluir) e os itens reais reais são excluídos de maneira cascata.

As tabelas de espelhamento são idênticas à tabela real com a adição de 3 colunas, "ChangeType", "Usuário", "Data".

Isso tem a dupla vantagem de poder excluir dados corretamente, mas também permitir que o estado do banco de dados seja recriado a qualquer momento e que o histórico completo de qualquer item seja documentado.

Acrescentarei que, para exclusões em cascata, geralmente prefiro exclusões em cascata no cliente - o servidor não deve tentar ser muito inteligente quanto a isso, se um usuário excluir uma empresa e que tiver problemas associados - a ação excluir empresa também deve excluir quaisquer registros correspondentes.

Isso era para um sistema de gestão financeira de um grande banco de investimento, portanto a auditabilidade era uma característica crítica.

Faça isso explicitamente na instrução delete / undelete. Provavelmente, também existem vários cenários em que você não deseja colocar em cascata a exclusão.

> Update table1 set deleted=@flag where...
> Update table2 set deleted=@flag where...

Por exemplo; considere uma pessoa com vários endereços.

Para excluir a pessoa, basta definir o sinalizador Excluir na pessoa. Não há necessidade de colocar em cascata a exclusão nos endereços, porque quando restauramos, queremos esses endereços de volta.

Digamos que a pessoa se mudou, então queremos atualizar o sinalizador de exclusão apenas no endereço antigo, deixando os outros endereços e a pessoa sozinhos. Portanto, a cascata nem sempre é necessária e depende do cenário.

Então, acho que você precisa ser explícito, dependendo de como seu modelo está configurado e de qual sua exclusão.