[firebase-br] DELETE CASCADE

[Carlos H. Cantu]

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