Emerson, > Mozart Hasse escreveu: > > A trigger tem a intenção de atualizar os valores de alguns campos (saldo > > anterior e data inicial do próximo registro) no registro recém incluído, de > > forma a deixar o registro incluído com valores coerentes com os registros > > anteriores e posteriores, segundo um determinado critério de ordenação. > > pq vc não faz uma trigger *Before Insert* e muda o valor antes dele ser > gravado? > > assim > new.nomedocampo = (SELECT blablabla); > > e outra trigger no after delete para atualizar (um laço) os registros > afetados (acredito que sejam todos os posteriores)
O problema é que eu teria de aplicar uma regra de negócio complicadíssima sobre o registro inserido/alterado (adaptando umas 500 linhas de querys para consultar os outros registros incluindo o NEW) e manter essa mesmíssima regra duplicada em outro trecho que atualiza os registros posteriores ao que foi atualizado (independente do NEW/OLD). Corro ainda o risco de precisar triplicar essa regra ao fazer uma trigger específica para o UPDATE e outra para o DELETE. Eu já tenho um roteiro de testes bastante extenso para validar isso considerando que a regra de negócio está em um lugar só, e se eu precisar duplicar o código vou tornar meu processo de homologação ainda mais complexo, além de piorar *muito* a minha manutenção daqui por diante. Posso tentar fazer isso pelo ganho esperado em desempenho e redução no tráfego de rede, mas vai ser bem difícil vender essa idéia (duplicação de regra de negócio) devido ao custo de manutenção posterior, pois vai exatamente e radicalmente contra todos os nossos esforços. Agradeço a sugestão, em último caso vou segui-la, porém ainda estou à procura de uma opção que não dê ao Postgres um diferencial tão negativo frente ao SQL Server/Oracle. Atenciosamente, Mozart Hasse _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
