[firebase-br] RES: DELETE CASCADE

Seg Nov 12 16:54:47 -03 2012

Boa tarde,

Agradeço a todos pelas recomendações/sugestões...

Detalhando melhor processo, sim hoje são deletados os registros 'desnecessários', mas porque existe trigger's que disparam um processo de auditoria consolidade, que evita diversos problemas e permite rastrear qualquer informação caso necessário. 

Ainda sobre o delete cascade, se a tabela itens de venda tem uma FK (normal) relacionada com a venda, ao tentar deletar a venda primeiro, ocorre um erro quando há registro na tabela de itens, ok. 

Mas quando a FK é criada com o DELETE CASCADE isso é permitido (deletar primeiro os registros da tabela pai), consequentemente isso fica registrado na ordem 'errada' no processo de auditoria, indicando que primeiro foi deletado o registro da tabela pai, sendo que somente no Firebird funciona assim.

Além do processo de auditoria, há outras checagens que precisam ser realizadas, como por exemplo, ao deletar um item é necessário chegar qual é a filial (informação esta que está na tabela venda) para atualizar o saldo de estoque, mas essa informação fica indisponivel quando usa-se delete cascade.

Concordo, que usando uma trigger, pode-se deletar na ordem 'correta', mas quando a tabela pai tiver uma 'segunda' tabela  filha, teremos que tratar particularmente cada situação, para não deletar os itens da 'primeira' tabela filha indevidamente quando, por exemplo, a 'segunda' tabela filha impede o delete na tabela pai.

Tratar particularmente cada situação, para bases de dados com +/- 2300 tabelas, pode se tornar inviável.

Jonas Rodrigo Pacheco
Administrador de Banco de Dados

-----Mensagem original-----
De: lista [mailto:lista-bounces em firebase.com.br] Em nome de Alysson Gonçalves de Azevedo
Enviada em: sexta-feira, 9 de novembro de 2012 20:48
Para: Carlos H. Cantu; FireBase
Assunto: Re: [firebase-br] DELETE CASCADE

Fugindo um pouco do quesito banco de dados e falando sobre integridade, e complementando o Cantu.

Registro de inventário de itens e registro de vendas é um ponto muito crítico num sistema.
Se você deleta uma venda do banco e ocorre um problema com os itens, a principal pista de onde está o problema foi deletado.

Eu desaconselho forte deletar a venda. Mas sim marcar a venda com uma flag "apagado", gravar a data da exclusão, quem excluiu e até mesmo um motivo, se possível. Ai então faria os estornos dos itens envolvidos.
Por que se não fica muito vulnerável.

Um usuário pilantra faz uma venda de 10 itens (e recebe o dinhero de 10 itens), depois apaga essa venda e cria uma nova vendendo 7 itens (e embolsa a diferença). "E a diferença de 3 itens? Pau do sistema".
E como a venda original foi deletada, já era a prova de defesa do sistema.

Isso sem falar de uma possível auditoria da receita procurando as vendas declaradas nas NFEs, já que eu não entendo muito sobre isso e não sei como funciona.

Esse exemplo é para um caso de uma venda consumada, mas aplica para qualquer outra coisa que envolva os produtos da loja. Tudo que movimente os itens devem ser preservados para evitar esse tipo de problema.

Alysson Gonçalves de Azevedo - (11) 984 917 730

"É curioso como as pessoas ficam confusas quando a frase não terminam do jeito que elas periquito."

Em 9 de novembro de 2012 17:26, Carlos H. Cantu
<listas em warmboot.com.br>escreveu:

> GS> Estou de acordo.Porém com o passar do tempo e a substituição da 
> GS> equipe de TI entra o fator de imprevisibilidade.
> GS> Mesmo profissionais bons exitam mexer em algo que doravante há 
> GS> suspeita de que nem tudo tá na documentação (se ela existir) 
> GS> deixada
> pela equipe anterior.
> GS>  Toda vez que vejo uma noticia como a que lí ontem onde a vivo 
> GS> vendeu milhares de aparelhos com valor zero por falha de sistemas, 
> GS> eu vejo um programador ou DBA sendo sacrificado por imperícias com 
> GS> banco de dados. Como disse, não sou contra triggers, mas evito 
> GS> utliza-las como design de banco de dados.
>
> Mas a situação que vc descreve não se restringe a banco de dados ou 
> triggers, pode acontecer na aplicação tb. Por isso é importante uma 
> boa documentação e testes unitários (infelizmente, na maioria das 
> vezes, pura utopia).
>
> GS> Para mim, 'delete on cascade'  envolvendo triggers é o caminho 
> GS> mais rápido para se chegar ao inferno, não no momento imediato, 
> GS> mas em algum momento no futuro. Se tiver que usa-la é porque 
> GS> qualquer outra opção se tornou inviável.
>
> Eu implemento DELETE nos triggers somente quando eu tenho certeza 
> absoluta que os filhos devem ser removidos sem causar "efeitos 
> colaterais". Em situações onde os relacionamentos não são tão óbvios 
> para os usuários, eu prefiro não implementar e deixar que eles apaguem 
> manualmente as dependências.
>
> Exemplo:
>
> Implementar as FKs que referenciam um produto com DELETE CASCADE (ou 
> mesmo através de trigger), na minha opinião, é loucura, pois apagando 
> um produto iria "detonar" notas fiscais, pedidos, cotações, etc. que 
> já existiam e referenciavam o mesmo.
>
> []s
> Carlos H. Cantu
> www.FireBase.com.br - www.firebirdnews.org www.warmboot.com.br - 
> blog.firebase.com.br
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br 
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>
______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br Para saber como gerenciar/excluir seu cadastro na lista, use: http://www.firebase.com.br/fb/artigo.php?id=1107
Para consultar mensagens antigas: http://firebase.com.br/pesquisa