Re: [oracle_br] Re: Trigger de monitoramento de tran sação
Sim, sei bem que às vezes é difícil, mas pelo menos vc demonstrou seus conhecimentos técnicos, expôs as alternativas técnicas, e explicou os Riscos envolvidos, principalmente de custos e performance, né ? Se depois de fazer isso neguim nem te deu pelota é como eu falei, vc tapa o nariz e faz, depois se neguim reclamar dos resultados não-ótimos vc só aponta teu texto e diz "eu te disse, eu te disse" Espero que tenham sido úteis minhas observações sobre o AUDIT nativo, sobre as alternativas built-in (como o LOGMINER, mas sem esquecer do FGA, que eu ia esquecendo!!) e o link sobre a rotina de criação automatizada de triggers no caso de muitas tabelas a auditar via trigger de DML... []s Chiappa
Re: [oracle_br] Re: Trigger de monitoramento de tran sação
Então Chiappa!!! Eu até tentei argumentar, mas k... É melhor deixar pra lá. Eu fiz um negócio bem simples aqui e mandei. Em 22 de fevereiro de 2017 19:12, jlchia...@yahoo.com.br [oracle_br] < oracle_br@yahoogrupos.com.br> escreveu: > > > cara, primeiro observo que para procedimento técnico não tem essa do > cliente "querer" : se ele tiver uma razão ** séria ** e tecnicamente válida > para a recusa ok, a gente escuta, mas se não não faz sentido ele palpitar > no que não sabe... Não é você o Consultor, que eles estão Pagando pelo > conhecimento técnico ?? Então No máximo, se eles insistirem, se municia > no asktom que vc acha artigos dizendo com todas as letras que via de regra > QUALQUER built-in do RDBMS é muito mais performático (por ser escrito em C > compilado ** e ** situado no kernel do banco , versus a sua coitada rotina > em PL/SQL interpretado E externa ao kernel), além de ser Muito mais ** > barato ** para implementar (eles não tiveram que pagar as ** várias ** > horas/homem de programação necessárias), E como complemento via de regra é > ** muito ** mais Estável (pois foi escrito por um TIME de desenvolvedores, > depois sujeito a code review, bem diferente do programador eu-sozinho que > acho ser o seu caso)... > APRESENTA esses argumentos pro teu cliente, que daí se por Teimosia, > burrice ou qquer razão não-técnica ele não os aceitar vc FEZ a sua > obrigação : mais tarde se neguim reclamar do custo, do tempo que levou pra > desenvolver ou da Estabilidade da solução customizada, vc tem aonde > apelar... > > Só digo de novo : > > 1. Não Deixe de validar as outras auditorias built-in além do comando > AUDIT, principalmente a possibilidade de log miner > > e > > 2. se for programar, não deixe de checar se a tua versão de banco > permite coisas como a trigger de DDL após AUDIT, para fazer Combinações > entre o nativo e o customizado > > e > > 3. se vc for precisar lançar mão da técnica de criar uma trigger de DML > pra cada tabela a Auditar, estude ** carinhosamente ** os links que te dei > > > []s > >Chiappa > >
Re: [oracle_br] Re: Trigger de monitoramento de tran sação
cara, primeiro observo que para procedimento técnico não tem essa do cliente "querer" : se ele tiver uma razão ** séria ** e tecnicamente válida para a recusa ok, a gente escuta, mas se não não faz sentido ele palpitar no que não sabe... Não é você o Consultor, que eles estão Pagando pelo conhecimento técnico ?? Então No máximo, se eles insistirem, se municia no asktom que vc acha artigos dizendo com todas as letras que via de regra QUALQUER built-in do RDBMS é muito mais performático (por ser escrito em C compilado ** e ** situado no kernel do banco , versus a sua coitada rotina em PL/SQL interpretado E externa ao kernel), além de ser Muito mais ** barato ** para implementar (eles não tiveram que pagar as ** várias ** horas/homem de programação necessárias), E como complemento via de regra é ** muito ** mais Estável (pois foi escrito por um TIME de desenvolvedores, depois sujeito a code review, bem diferente do programador eu-sozinho que acho ser o seu caso)... APRESENTA esses argumentos pro teu cliente, que daí se por Teimosia, burrice ou qquer razão não-técnica ele não os aceitar vc FEZ a sua obrigação : mais tarde se neguim reclamar do custo, do tempo que levou pra desenvolver ou da Estabilidade da solução customizada, vc tem aonde apelar... Só digo de novo : 1. Não Deixe de validar as outras auditorias built-in além do comando AUDIT, principalmente a possibilidade de log miner e 2. se for programar, não deixe de checar se a tua versão de banco permite coisas como a trigger de DDL após AUDIT, para fazer Combinações entre o nativo e o customizado e 3. se vc for precisar lançar mão da técnica de criar uma trigger de DML pra cada tabela a Auditar, estude ** carinhosamente ** os links que te dei []s Chiappa
