QUE PAPEL DEVO DAR A MINHA CONTA?
Quero que minha aplicação (VB.NET) acesse um Banco de dados no SQL Server Express (2005).
Minha dúvida é a seguinte:
Dúvida:
Considerando-se que minha aplicação terá de ter acesso completo ao Banco de Dados,para
poder manipular as tabelas,etc...o correto é:
1.) Criar uma conta de usuário nova e usar a mesma para a aplicação fazer a conexão com o Sql Server , ou usar uma das
contas padrão criadas na instalação do Sql Server 2005???
2.) No caso de criar uma conta nova, que papel devo atribuir a mesma, para que minha aplicação tenha acesso e permissão
para tudo?
O sistema tem uma conta padrão para acesso ao banco, onde irá buscar os usuários que tem acesso ao bd, isso e mostrado na tela de login, relacionando em um combobox os usuarios.
Cada usuário novo no sistema é cadastrado no servidor. Não utilizo tabelas particulares para login, sempre utilizo a própria estrutura do banco.
Já com relação ao restrições de uso, utilizo uma tabela para adicionar as permissões de uso do sistema.
Conforme a imagen abaixo que é do meu sistema :
A alguma razão para você não querer utilizar uma tabela, para guardar o nome dos usuários que forem sendo
cadastrados no Sistema?
Crie um usuário do seu sistema no banco SQL, atribua a ele apenas permissao para acessar View[ô]s e Procedures, dessa forma se algum usuário [Ô]malandro[Ô] descobrir seu usuario e senha do BD ele nao conseguirá acessar as tabelas do Banco, apenas as View[ô]s! Dessa forma ele nao altera a estrutura do banco!..é uma regra de segurança mto usada em sistemas web.,,,
Citação::
Olha realmente existem mtas formas de fazer isso, mas tenho uma sugestao (principalmente se estiver criando um sistema novo):
Crie um usuário do seu sistema no banco SQL, atribua a ele apenas permissao para acessar View[ô]s e Procedures, dessa forma se algum usuário [Ô]malandro[Ô] descobrir seu usuario e senha do BD ele nao conseguirá acessar as tabelas do Banco, apenas as View[ô]s! Dessa forma ele nao altera a estrutura do banco!..é uma regra de segurança mto usada em sistemas web.,,,
Lembra o encapsulamento em POO.
Tem tanta coisa sobre boas práticas que ando lenfo que já to ficando maluco.
Muito interessante sua colocação (Do ponto de vista de segurança). Mas isto significará fazer
boa parte da programação no própio BD.Cabe aqui duas perguntas:
1.) Do ponto de vista das boas práticas, o correto é de fato fazer toda programação (Regras de negócio) no SGBD???
2.) Que papéis (Do Sql Server) devo atribuir a uma conta, para que a mesma tenha acesso somente as visões e Procedures???
Citação::
FoxMan,
A alguma razão para você não querer utilizar uma tabela, para guardar o nome dos usuários que forem sendo
cadastrados no Sistema?
Sim....Utilizar o máximo dos recursos que o SGBD pode me oferecer.
Se posso cadastrar usuários no SGBD então não preciso me preocupar com uma tabela somente para esta finalidade.
Citação::
LLAia,
Muito interessante sua colocação (Do ponto de vista de segurança). Mas isto significará fazer
boa parte da programação no própio BD.Cabe aqui duas perguntas:
1.) Do ponto de vista das boas práticas, o correto é de fato fazer toda programação (Regras de negócio) no SGBD???
2.) Que papéis (Do Sql Server) devo atribuir a uma conta, para que a mesma tenha acesso somente as visões e Procedures???
1) Nao Recomendo!!..Seguindo as boas práticas o correto é vc usar uma [Ô]Camada de Negócios[Ô] onde vc coloca toda a regra de negócios nela...como contruir essa camada vai depender da arquitetura do seu software, pode ser um outro projeto referenciado ou também um componente...A ideia é sempre pensar: Quem mais pode consumir esse processo de negócio?...Pense em um ambiente Web, um desktop e um mobile consumindo a mesma regra de negócio...dessa forma verá a facilidade na manutenção do legado e no aumento do tempo de vida do software!...
Ah mas vc pode se perguntar: Mas já q o Banco de Dados é único para todos os ambientes posso usá-lo para a regra de negócio? Não gosto da ideia por alguns motivos:
- Creio ser bem mais fácil controlar uma transação pela aplicação;
- No banco de dados geralmente é usado uma programação procedural o que dificulta e MUITO a manutenção da regra de negocio;
- Existe uma tremendaaaa dificuldade para debugar o código em runtime
- Dificuldade em controle de versoes (Já existe controle de versoes de scripts de bd, mas nao tao comuns em pequenas empresas);
Bom, sei q existem vantagens tb, ex: tornar a regra de negócio independente de uma determinada linguagem de programação (pode mudar de java para .NET sem problemas)
A escolha é sempre sua...rs
2) Adiciona os objetos ao schema de segurança do usuário do Sql..
Espero ter ajudado!
Att
Thiago
Citação::
LLAia,
Muito interessante sua colocação (Do ponto de vista de segurança). Mas isto significará fazer
boa parte da programação no própio BD.Cabe aqui duas perguntas:
1.) Do ponto de vista das boas práticas, o correto é de fato fazer toda programação (Regras de negócio) no SGBD???
2.) Que papéis (Do Sql Server) devo atribuir a uma conta, para que a mesma tenha acesso somente as visões e Procedures???
Então, ainda estou estudando e não sinto a vontade para te indicar um caminho, até porque existem muitos! Hoje em dia, muitos tem usado o SGBD como um simples repositório de dados (desprezando muitas de suas funcões peculiares) devido a abordagem e arquitetura adotada.
Olha como isso é uma questão complicada. Leia esse post e os comentários dos participantes sobre se ORMs decretaram o fim de stored procedures.
http://devbrasil.net/group/adonet/forum/topics/chegou-ao-fim-o-uso-de-stored