Pular para o conteúdo
Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • 29 de março de 2016 at 1:21 am #108099
    Avatar de João Adriano BassoJoão Adriano Basso
    Participant

      Caros,

      Queria criar uma trigger que impedisse a realização do comando update sem a clausula “where”. Alguém tem ideia?

      29 de março de 2016 at 11:52 pm #108100
      Avatar photoJosé Laurindo Chiappa
      Moderator

        Blz ? Então, possível é em tese, vc (ou mais precisamente, o DBA/admin desse database) poderia criar uma trigger de DDL que capturasse o texto do SQL em execução, e num IF se não encontrasse a string WHERE nesse texto de SQL abrotasse a trigger : alguns exemplos genéricos de trigger de DDL que podem te servir de base/ponto de partida são https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:33373327079924 , https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:1433604222919 , http://www.morganslibrary.org/reference/undocumented.html#onlt , https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::p11_question_id:267415465220 e http://www.morganslibrary.org/reference/plsql/ddl_trigger.html …

        Agora, tenha em mente que :

        a) num database profissionalmente Administrado, que seja de Produção, o *** mínimo *** que se espera é que haja um processo de CONTROLE / PROMOÇÃO de código, ie, QUALQUER código (seja SQL, PL/SQL ou o que for) primeiro é TESTADO num database de testes e só depois o DBA (ou um administrador, pelo menos) é que aplica esse código no database, Obviamente checando a Qualidade dele, se assegurando que UPDATEs (e todos os SQLs, na verdade) estão com as colunas-chave corretas não trabalhando nas tabelas inteiras, que esse código não está fazendo full table scan, LOCKS de montão, não contém código malicioso tentando acessar dados que não lhe pertencem, é por aí….
        CASO vc esteja pensando nisso por não ter controle de qualidade e restrições de acesso / promoção de código no seu database, IMHO ao invés de macetear com triggers o CORRETO e PROFISSIONAL seria vc implementar tais controles / fluxos de trabalho nesse ambiente..

        b) tal trigger NÂO VAI parar 100% do código ruim que algum despreparado com acesso esteja enviando pra esse database : nada impede, por exemplo, de neguim meter um WHERE 1=1, ou outra condição que sempre é verdadeira, e aí continuar trabalhando / acessando a tabela full, ok ?
        Quanto mais casos fake/de violação a best practices de SQL vc botar na lógica do trigger, via de regra mais “criativos” teu usuários ficam – não pense que vc consegue barrar 100% das possibilidades, que não consegue não…

        []s

        Chiappa

      • Author
        Posts
      Viewing 2 posts - 1 through 2 (of 2 total)
      • You must be logged in to reply to this topic.
      plugins premium WordPress