Caro Eder, se você é iniciante em Banco de Dados, vou lhe dar uma dica de quem já pastou um pouco por aí!
Não faça isso! Ter vários usuários autenticando diretamente do seu SGDB pode ser um verdadeiro pesadelo! Eu sei, também já cometi este equívoco e sei até que existem muitos desenvolvedores que gostam desta idéia. Mas vou dizer os motivos pelo qual é melhor não fazê-lo: 1) Segurança: se cada usuário possui acesso direto a base, eles poderão configurar um ODBC, ou utilizar qualquer ferramenta gráfica (existem muitas) baixadas pela internet e se conectar direto na base. Você não vai querer seus usuários apagando e alterando dados diretamente no SGDB sem passar pela aplicação. 2) Controle de Acesso: se você quiser controlar o acesso a telas específicas do sistema, ou restringir a consulta do usuário a uma faixa de valores (por exemplo os dados dos clientes que ele gerencia), o Banco de Dados não vai lhe permitir isto, então você vai ter que criar uma estrutura separada em uma tabela para controlar isto, ou seja vai ter mais trabalho que antes! 3) Backup: os usuários do SGDB não entram no dump ao fazer backup do banco de dados. Você tem que fazer isto manualmente acessando as tabelas ou views de sistema do banco, como o "Information Schema". Como o normal é ter apenas um punhado usuários no banco, normalmente desenvolvedores, DBAs e "usuáios muito especiais", não chega a ser um problema. 4) Sincronia de senhas: se você quiser atualizar uma base de dados de teste com os dados do banco de dados de produção, verá que os usuários do SGDB não serão atualizados, o que é bom para os desenvolvedores, mas pode ser ruim, se você quiser que um usuário teste uma nova funcionalidade da aplicação e não lembre a senha antiga dele. Se os dados do usuário estiverem numa tabela a parte, isto não será problema, pois os usuários e senhas serão atualizados automaticamente. 5) Manutenção: é função do DBA verificar quais usuários tem ou não acesso direto ao Banco de Dados, você não vai querer ter de ficar atento a todas as novas contratações, férias e demissões na empresa para ficar criando, apagando, ativando e desativando contas. Também não vai querer que sua aplicação tenha poder para fazer isto direto no banco de dados, não seria bom para a segurança da sua aplicação fazer isso. Bom, acho que é isso.... o barato pode sair caro, principalmente em termos de segurança. []s Fábio Telles Em 08/02/07, Euler Taveira de Oliveira<[EMAIL PROTECTED]> escreveu: > Eder wrote: > > > R = Euler como eu disse, não entendo muito de banco de dados, mais > > discordo de você, em relação a maior controle. O controle efetuado > > pelo banco de dados é definitivo, um bom gerenciamento de acesso no > > banco ira assegurar a minha aplicacao e qualquer outra coisa que o > > usuario utilize para acessar o banco. > > > Acho que você me entendeu mal. O controle a que refiro é o controle > sobre os dados. O SGBD faz um controle a nível de estrutura (colunas, > tabelas, visões, funções, etc), mas ele não consegue controlar se um > dado registro na tabela 'foo' pode ser acessado pelo usuário 'bar'. > > > Eu olhei a documentação, mais não encontrei nada em relação ao que eu > > quero fazer, eu precessaria arrumar alguma forma do usúario do próprio > > SGBD ver a sua matricula, onde estará suas permissões de acesso, pelo > > menos por enquando. > > > Ainda não entendi o que deseja fazer. Você queria que o usuário 'fulano' > consultasse a matrícula que está em uma tabela e utilizar esta matrícula > para fazer o acesso? Se for isso você vai ter que utilizar uma variável > de sessão para que a informação 'matricula' "propage" pelo sistema. > Caso queira fazer as permissões pelo SGBD mesmo, porque não criar o > usuário como sendo o número da matrícula? > > regression=# create user "001234"; > CREATE ROLE > regression=# create user "001234-07"; > CREATE ROLE > regression=# \du > Lista de roles > Nome da role | Super-usuário | Cria role | Cria BD | Conexões | Membro > de > --------------+---------------+-----------+---------+-----------+----------- > 001234 | não | não | não | ilimitado | > 001234-07 | não | não | não | ilimitado | > postgres | sim | sim | sim | ilimitado | > (3 registros) > > regression=# > > > -- > Euler Taveira de Oliveira > http://www.timbira.com/ > > _______________________________________________ > Grupo de Usuários do PostgreSQL no Brasil > Antes de perguntar consulte o manual > http://pgdocptbr.sourceforge.net/ > > Para editar suas opções ou sair da lista acesse a página da lista em: > http://pgfoundry.org/mailman/listinfo/brasil-usuarios > -- site: http://www.midstorm.org/~telles/ e-mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] sip:[EMAIL PROTECTED] _______________________________________________ Grupo de Usuários do PostgreSQL no Brasil Antes de perguntar consulte o manual http://pgdocptbr.sourceforge.net/ Para editar suas opções ou sair da lista acesse a página da lista em: http://pgfoundry.org/mailman/listinfo/brasil-usuarios
