Oi Chiappa,
agora eu peguei o seu raciocínio - a forma de implementar isso
dependeria de inúmeras parafernálias tipo SQL dinâmico.
Sobre a queda de performance de SQLs dinâmicos, eu nem preciso ir no
Asktom.
Eu já fiz muitos testes e comprovo o que vc diz em número, genero e grau.
Mas siga o
Sim Josir, principalmente o custo em performance pra se implantar esse
tipo de admin é que me leva à contra-recomendá-lo. No seu argumento, a
primeira coisa é que SELECT ANY é um exemplo infeliz, ANY significa **
QUALQUER ** uma no banco de dados, evidentemente INCLUINDO as tabelas
internas do SYS
] Em
nome de jlchiappa
Enviada em: sexta-feira, 20 de julho de 2007 18:24
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: RES: [oracle_br] Conceder permissao a todos objetod de UM
schema
Renan, obviamente o .BAT *** não sabe *** nada vezes nada a respeito
de linguagem SQL, de PL/SQL, de banco
Chiappa,
me interessei pelo post :)
1) Vc podia dissertar sobre o porque não se deve administrar a segurança
dessa forma. Se um grupo de usuários tiver sempre direito a SELECT em
uma base, porque não utilizar o fictício:
GRANT SELECT ON [schema] to [role]
Acho que isso tá mais para uma
O porquê de não ser a melhor opção, em primeiro lugar é por que pra
implementar isso vc VAI TER QUE, como eu disse, criar triggers/jobs
que criem SQLs dinâmicos com DDL, e há imposto de performance se
houver abuso tanto para SQL dinâmico (parses extras) quanto para DDLs
(invalidação de objs,
