Usuário com melhor resposta
Como forçar o comando UPDATE ou DELETE sempre ter a condição "WHERE" para ser executado?

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 ****
- Editado Rafael dos Santos Silva terça-feira, 26 de novembro de 2013 12:25 Melhora da pergunta
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)
- Editado Fulvio Cezar Canducci Dias terça-feira, 26 de novembro de 2013 13:06
- Marcado como Resposta Rafael dos Santos Silva terça-feira, 26 de novembro de 2013 13:30
Todas as Respostas
-
-
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/
-
-
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!!!
-
-
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 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 ****
- Editado Rafael dos Santos Silva terça-feira, 26 de novembro de 2013 12:33 Melhora da pergunta
-
-
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 ****
-
- Editado Fulvio Cezar Canducci Dias terça-feira, 26 de novembro de 2013 12:54
-
-
-
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)
- Editado Fulvio Cezar Canducci Dias terça-feira, 26 de novembro de 2013 13:06
- Marcado como Resposta Rafael dos Santos Silva terça-feira, 26 de novembro de 2013 13:30