Bem meus amigos, creio que muito já se depararam com a seguinte situação: A necessidade de usar Pool de Conexão para as aplicações WEB e OBRIGAÇÃO(No meu caso obrigação, pois a $$ que gastaram com a licença do Oracle tem que servir pra alguma coisa, senão os DBA’s me matam!) de usar vários usuários no SGBD.
:arrow: Gostaria de saber se alguem trabalha dessa forma (Usando vários usuários do BD), qual a solução que vocês adotaram?Framework?Qual?
:arrow:Como o GUJ (Portal) funciona?Para cada usuario aqui creio que seja um registro na Tabela Usuário, por exemplo, pois aqui são muitos usuários. Estou certo?
Juloko, não concordei com o que você falou.
Cada usuário aqui no GUJ é um usuário (um registro) na tabela de usuário… perfeito. mas todos usam o mesmo login/senha para conectar no BD.
No seu caso é a mesma coisa. Você não precisa obrigatoriamente de mais de um usuário para conectar sua aplicação no BD.
O que você quer criando diversos login/senha para a sua aplicação ? Controlar direitos de acesso do usuário? Quem deve fazer isso é aplicação.
Por favor, não ache que cada usuário com seu próprio login de banco de dados vai facilitar o controle de leitura/update/insert em diferentes tabelas do seu BD. Não faz sentido nenhum isso.
Cara, resumindo. Faça sua aplicação usando apenas um login/senha para conectar a aplicação no BD. Se depois aparecer alguma necessidade que te faça alterar isso, tudo bem. Mas espere aparecer a necessidade. Acho pouco provável que ela apareça.
A licença do BD não te obriga a usar diversos logins. Ela te dá direito a x conexões simultaneas independente se são o mesmo login ou não.
Abraço.
juloko666
Arcadex, um exemplo: tenho uma aplicação que utiliza Pool de Conexão, no Context.xml eu defino XXX como sendo usuário do Banco. Eles(Os DBA’s) querem que cada usuario do sistema seja um usuario do banco, entende?(Neste caso, são poucos usuarios).
Motivo de tudo isso->Eles criaram ROLES espefícas para o usuario tendo controle de tudo o que ele faz(Todas as alterações).
PS: Vou pesquisar sobre Hibernate, pelo que vi muitas empresas utilizam, quero ver quais suas vantagens.
Abraços e obrigado!
Arcadex
Juloko, na boa. Nunca vi um DBA fazer um tipo de requisição como essa. Pode escrever o que estou falando. Essa idéia deles não vai p/ frente !!! Se for, qdo estiver pronta vão ver que fizeram merda, não serve p/ nada e que foi idiotice.
Tenho certeza do que estou falando.
Cara, controle sobre o que um usuário faz, toda aplicação (toda não, 99%) precisa fazer. No entendo, nenhuma fica conectando no BD c um usuário diferente. Será que todo mundo está errado. Claro que não! Existem formas muitos melhores para se fazer isso. Você consegue identificar o usuário logado sem que ele tenha que se conectar com um login de BD específico.
Os DBAs estão querendo colocar a lógica da aplicação no BD ?
Se sim, fale com eles que vc vai colocar a tabela no código fonte da sua aplicação (cada um na sua praia).
juloko666
Talves seja porque a experiencia que eles tiverem foi com Visual Basic 6 Client-Server e eles utilizavam dessa forma(Um usuário do BD, para cada usuário da aplicação(Cerca de 15))…
Bem obrigado e deixo aqui minha pergunta quanto ao próprio portal GUJ, vocês utilizam Pool de Conexão ou há outra tecnologia para administrar o fluxo de requisições do Banco de Dados?
Obrigado!
alexandremlima
Aqui na empresa usamos esse esquema de usuário no banco de dados.
Devido ao legado do mainframe, os usuários são criados num software (Hackf) ligado ao sistema operacional do mainframe (MVS). Quando o usuário é criado nesse software, tanto o S.O. como o banco de dados (DB2) passam a usá-lo para controlar as permissões. Esse software define tudo com relação a permissões de arquivos, tabelas e elementos dentro do mainframe.
Assim, não podemos utilizar um pool de conexões aqui na empresa porque os DBAs e os administradores do mainframe querem saber o que cada usuário está fazendo dentro do mainframe e auditar isso com outro software do mainframe.
Nas nossas classes DAOs, os métodos recebem um objeto da classe Usuario que contém o usuário autenticado no momento na aplicação. Isso é usado para abrir uma conexão com o banco de dados (passando o login e a senha do usuário), executar o que tem que ser feito e fechar essa conexão. No momento em que esse método do DAO está sendo executado, os DBAs conseguem ver no console do mainframe o que está sendo executado pelo usuário e assim poder tomar uma providência se der algo de errado.
A
Alexandre_Ferreira1
Não curti essa ideia.
Ate porque as consultas sao sempre as mesmas independente da ANTA que esta logada.
É muito melhor criar uma tabela chamada log. E adicionar aos seus DAOs um insert sempre que a pessoa fizer update ou insert salva o ID da pessoa, hora e data, o valor antigo , e o valor novo…
Porque monitorar select é importante?Se for tao restritivo o seu select e pode tras informacoes que nao deveriam vir para todos os usarios.Trabalhe com restricoes e permissoes, não é mais inteligente?
Não vejo tamanha atitude valida…
Vale a pena “Loggar”(ação,logging) tanto ao inves de perfomance ou custo?
Mande metade desses DBA que fingem monitorar isso 8hrs/dia e aumenta o salario dos desenvolvedores que ficam batendo a cabeca porque esses doentes so falam merdas =P (…momento desabafo…)
Perder o Pool de Conexao por monitoracao? BESTEIRA PURA!
