[firebase-br] Para Carlos Cantu e demais

Eduardo Jedliczka - TeamFB jedyfb em gmail.com
Sáb Fev 23 09:29:39 -03 2008


Precisamos sempre levar em consideração que na informática sempre existe
3 milhões de formas diferentes de se fazer a mesma coisa.... algumas
mais fáceis, outras mais difíceis, umas mais rápidas, outras nem tanto,
umas mais limitadas, outras mais abrangentes e flexíveis, umas mais....
outras menos...

Penso que cada caso é um caso, e várias vezes vale à pena "quebrar"
certas regras para se conseguir boa performance ou para conseguir
segurança extra...

Sou muito a favor de usar Update Cascade, mas muito contra a usar Delete
Cascade, principalmente porque certos tipos de documentos não devem ser
excluídos do sistema em nenhuma situação, mas devem ser "cancelados" ou
"extornados", assim dificulta a fraude por parte de um funcionário
"mal-intensionado"

Claro que há casos em que usamos triggers para recompor saldo, ou
validar regras de negócios (por exemplo, não faturar notas com menos de
três itens, ou não despachar via transportadora menos de 2 volumes) que
devem ser "validados" antes de um before delete ou after insert... um
update cascade ou delete cascade pode gerar uma bela dor de cabeça,
rompendo facilmente esta regra.

Há casos também que tive que optar por "eliminar uma FK" que estava
matando o desempenho do banco... havia um relacionamento entre 3 tabelas
(todas com codigo da empresa, codigo da filial e codigo do produto) mas
a maior delas tinha 2 milhões de registros e a menor tinha menos de 100
registros... todos os selects com inner join ou left join usavam índices
horríveis (pegavam a foreign key da tabela menor ao invés da PK da
tabela maior), e não sou adepto de "forçar" um índice no banco. Ao
apagar a foreign Key, e criar uma Check Constraint com select EXISTS
mantive o praticamente mesmo desempenho nos inserts, e tive um ganho
absurdo em todos os joins.

Isto são decisões que precisam ser analisadas e ponderadas com muito
cuidado... tem-se que documentar muito bem e ter certeza que será
questionado sobre o assunto... e é claro, não se faz em produção antes
de se fazer muitos e muitos testes....

Sucesso,

Eduardo Jedliczka

Em Sex, 2008-02-22 às 23:15 -0300, Felipe Oriani escreveu:
> hahahahaha... é então... meio anda pra traz não utilizar este recurso que o
> banco fornece!!!
> 
> Brincadeiras a parte: "mas se o Cantu faz... eu tbm vou fazer..."
> ahuiahiuahauihauiahia... que coisa hein....hehehe
> 
> 
> 
> 2008/2/22, Carlos H. Cantu (TeamFB) <listas em warmboot.com.br>:
> >
> > Lógico que eu crio as FKs ;-)
> >
> >
> > []s
> > Cantu (Membro do TeamFB - FireBase)
> > http://www.warmboot.com.br
> > FireBase - http://www.FireBase.com.br
> >
> >
> > FO> Bem... estranho!!! Carlos, não entendi uma coisa...
> >
> > FO> Você chega a criar a FK sem Cascade e depois cria a trigger e faz o
> > delete
> > FO> ???
> > FO> ou
> > FO> simplismente faz o delete na trigger, sem criar a FK ???
> >
> > FO> Isso não geraria um perigo de inconsistência nos dados ???
> >
> >
> >
> >
> > ______________________________________________
> > 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
> >
> 
> 
> 





Mais detalhes sobre a lista de discussão lista