[firebase-br] DELETE CASCADE

[Alysson Gonçalves de Azevedo]

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) 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
>