Pular para o conteúdo
  • Este tópico contém 1 resposta, 2 vozes e foi atualizado pela última vez 8 anos, 4 meses atrás por Avatar photoJosé Laurindo Chiappa.
Visualizando 2 posts - 1 até 2 (de 2 do total)
  • Autor
    Posts
  • 29 de março de 2016 às 1:21 am #108099
    Avatar de João Adriano BassoJoão Adriano Basso
    Participante

      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 às 11:52 pm #108100
      Avatar photoJosé Laurindo Chiappa
      Moderador

        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

      • Autor
        Posts
      Visualizando 2 posts - 1 até 2 (de 2 do total)
      • Você deve fazer login para responder a este tópico.
      plugins premium WordPress