none
Como forçar o comando UPDATE ou DELETE sempre ter a condição "WHERE" para ser executado? RRS feed

  • Pergunta

  • Olá pessoaL

    Gostaria de saber se existe uma possibilidade de fazer os comandos UPDATE e DELETE forçando sempre ter a condição WHERE para que ninguém consiga deletar ou atualizar todos os registros da tabela!


    Por exemplo, as vezes o programador T-SQL faz o comando

    UPDATE Tabela SET campo = 1 executa a instrução.

    o mesmo, por algum motivo como: falta de atenção, esqueceu de colocar o WHERE já que o objetivo principal era atualizar um registro especifico, e como o comando acima esta correto, o SGBS irá atualizar todos os registros.

    Se houve-se uma maneira para forçar isso, esse tipo de "erro", ou melhor, falta de atenção poderia ser erradicado.

    Lembrando que, por mais besta que seja, de um programador esquecer o WHERE para fazer um Update ou Delete acontece, certo pessoal?



    Att,

    Rafael.



    **** SER A RESPOSTA FOR UTIL, NÃO ESQUEÇA DE MARCA-LÁ =P ****



    terça-feira, 26 de novembro de 2013 12:03

Respostas

  • Rafael, acredito que todo DBA gostaria de que fosse bloqueada a execução de comandos DELETE e UPDATE sem a cláusula where.  rss

    Resolvi pesquisar na web e encontrei outros usuários com a mesma necessidade e até algumas sugestões:

    (1) Actually, I guess you could enforce this by preventing direct access to the table and forcing access via stored procedures. (Aaron Bertrand)

    (2) you could create a trigger that does a ROLLBACK of the update if the row count is the same as the count of rows in the table 

    (3) if your shop uses VSTS and TFS, an interesting option you can consider at the development stage itself, is to set up code analysis in VSTS Development Studio, for the particluatr database project in question. One of the things you can set up in code analysis is to check for DML statements that don't have a WHERE clause. You can also check for other things like there should be no SELECT * , etc.

    (4) if it is possible and does not impede the business functions, you could possible give the help desk guys and developers read-only permissions on the databases. 

    (5) Another approach to enable then to perform delete and updates - while still keeping their management studio permissions to read only - is for you to write a generic delete/update stored procedure that takes table name and where clause filter as inputs and uses dynamic sql to build and execute the query. this way, you can have a check in the proc so that it will not execute the query and throw back a meaningful error when the WHERE clause is missing. This approach will require you to write only 2 procs ( 1 for update and 1 for delete ) - revoke all permissions from helpdesk and developers and give them read permissions and execute permissions on your 2 DML procs. 

    etc etc.


        José Diz     Belo Horizonte, MG - Brasil
    (Se encontrou a solução nesta resposta, ou se o conteúdo foi útil, lembre-se de marcá-la)


    Pois é até concordo, mas, também a opção do Update e Delete de uma forma total, então, são comandos válido por isso existente e só bloqueados via usuários e permissões! Bular talvez por Procedure!!! mas, ai não executa o Update se o usuario for bloqueado .. kkk !

    Fulvio Cezar Canducci Dias


    terça-feira, 26 de novembro de 2013 13:05

Todas as Respostas

  • ????

    Ficou estranho sua questão!, tem um fato real a contar, algum cenário, como assim ???

    A única coisa que você impedir quem faz isso no Banco, ou até desenvolver procedure que obrigará passar paramentros nela!


    Fulvio Cezar Canducci Dias

    terça-feira, 26 de novembro de 2013 12:09
  • Eu acho que para o que você quer fazer, a única maneira de se controlar isso e gerenciando as permissões dos usuários que tem acesso ao banco.

    Para decidir quem pode realizar esse tipo de ação ou não.

    Creio que seja essa forma, talvez eu exista e eu não conheça :)

    Valeu o/

    terça-feira, 26 de novembro de 2013 12:12
  • Olha ai a nova descrição pra ver se ficou melhor! ^^'>

    **** SER A RESPOSTA FOR UTIL, NÃO ESQUEÇA DE MARCA-LÁ =P ****

    terça-feira, 26 de novembro de 2013 12:17
  • Amigo, mudando o titulo!

    não mudou a idéia que tinhamos!

    Se você dá permissão a um usuário a delete ou update se ele escrever errado vai rodar errado!

    Se você bloquear e fazer um procedure de banco e disponibilizar somente ela é um meio de bular!

    mas, sério não tem isso visto que as operação deveram ser executadas!!!


    Fulvio Cezar Canducci Dias

    terça-feira, 26 de novembro de 2013 12:18
  • Deleted
    terça-feira, 26 de novembro de 2013 12:24
  • Olá pessoaL

    Gostaria de saber se existe uma possibilidade de fazer os comandos UPDATE e DELETE forçando sempre ter a condição WHERE para que ninguém consiga deletar ou atualizar todos os registros da tabela!

    Rafael, uma solução de contorno seria criar rotina trigger para cada tabela, tratando instruções UPDATE e DELETE, e que verificasse se houve apagamento ou alteração para todas as linhas. Mas, ao detectar que todas as linhas foram apagadas ou alteradas, que ação seria tomada?


        José Diz     Belo Horizonte, MG - Brasil
    (Se encontrou a solução nesta resposta, ou se o conteúdo foi útil, lembre-se de marcá-la)


    O que faz falta e relatar José Diz porque quer fazer isso, qual o intuito principal ? o que acha!

    Fulvio Cezar Canducci Dias

    terça-feira, 26 de novembro de 2013 12:28
  • O motivo principal para fazer isso é evitar erros e futuros problemaS devido a falta de atenção de um usuário que irá executar o comando.

    Porque image se caso, sem querer, o user executa o comando sem a condição where. Ele irá afetar todas as tuplas da entidade e causar alguns danos.

    O principal foco para esse tipo de controle, seria evitar que falta de atenção ocorra e obrigue o usuário sempre utilizar um WHERE junto aos comandos de UPDATE E DELETE.


    **** SER A RESPOSTA FOR UTIL, NÃO ESQUEÇA DE MARCA-LÁ =P ****


    terça-feira, 26 de novembro de 2013 12:32
  • Deleted
    terça-feira, 26 de novembro de 2013 12:34
  • ISSO AEEE, ESSE TIPO DE PROBLEMA QUE QUERO EVITAR QUE ALGUNS USUÁRIOS FAÇAM!!!!!!!! Eu sei que no Mysql, no Workbench, temos uma opção no menu do SGBD que nos permite setar se deve ou não ter a condição WHERE em Update ou DELETE!!

    **** SER A RESPOSTA FOR UTIL, NÃO ESQUEÇA DE MARCA-LÁ =P ****

    terça-feira, 26 de novembro de 2013 12:36
  • Então sempre faça isso numa banco de teste! antes de colocar no de produção!

    Concordam?


    Fulvio Cezar Canducci Dias


    terça-feira, 26 de novembro de 2013 12:54
  • O que faz falta e relatar José Diz porque quer fazer isso, qual o intuito principal ? o que acha!

    Fúlvio, eu acho que o objetivo é evitar isto aqui:


        José Diz     Belo Horizonte, MG - Brasil


    kkkk essa foi para acabar o dia kkk

    Fulvio Cezar Canducci Dias

    terça-feira, 26 de novembro de 2013 12:55
  • Deleted
    terça-feira, 26 de novembro de 2013 13:03
  • Rafael, acredito que todo DBA gostaria de que fosse bloqueada a execução de comandos DELETE e UPDATE sem a cláusula where.  rss

    Resolvi pesquisar na web e encontrei outros usuários com a mesma necessidade e até algumas sugestões:

    (1) Actually, I guess you could enforce this by preventing direct access to the table and forcing access via stored procedures. (Aaron Bertrand)

    (2) you could create a trigger that does a ROLLBACK of the update if the row count is the same as the count of rows in the table 

    (3) if your shop uses VSTS and TFS, an interesting option you can consider at the development stage itself, is to set up code analysis in VSTS Development Studio, for the particluatr database project in question. One of the things you can set up in code analysis is to check for DML statements that don't have a WHERE clause. You can also check for other things like there should be no SELECT * , etc.

    (4) if it is possible and does not impede the business functions, you could possible give the help desk guys and developers read-only permissions on the databases. 

    (5) Another approach to enable then to perform delete and updates - while still keeping their management studio permissions to read only - is for you to write a generic delete/update stored procedure that takes table name and where clause filter as inputs and uses dynamic sql to build and execute the query. this way, you can have a check in the proc so that it will not execute the query and throw back a meaningful error when the WHERE clause is missing. This approach will require you to write only 2 procs ( 1 for update and 1 for delete ) - revoke all permissions from helpdesk and developers and give them read permissions and execute permissions on your 2 DML procs. 

    etc etc.


        José Diz     Belo Horizonte, MG - Brasil
    (Se encontrou a solução nesta resposta, ou se o conteúdo foi útil, lembre-se de marcá-la)


    Pois é até concordo, mas, também a opção do Update e Delete de uma forma total, então, são comandos válido por isso existente e só bloqueados via usuários e permissões! Bular talvez por Procedure!!! mas, ai não executa o Update se o usuario for bloqueado .. kkk !

    Fulvio Cezar Canducci Dias


    terça-feira, 26 de novembro de 2013 13:05