Ir para conteúdo

POWERED BY:

Arquivado

Este tópico foi arquivado e está fechado para novas respostas.

devthiagolino

Autenticação

Recommended Posts

Olá rapazeada!

 

Seguinte, estou criando um serviço (SAAS), e que em relação a autenticação de usuário, eu estou planejando que:

- Nosso suporte tenham acesso a qualquer usuário, pois isso facilita os suportes.

Por exemplo: O cliente liga e diz que alguma área está com erro, dai nosso operador, acessará o ambiente do cliente, mas não com a senha do cliente e sim a senha do próprio operador.

- Facilita também o gerenciamento de operadores que trabalham com suporte, às vezes são demitidos ou coisas do tipo.

 

A minha sugestão a equipe de desenvolvimento foi:

- Cliente tem o banco de dados dele, e os usuário do cliente estarão nesse banco de dados;

- O ADMIN (operadores de suportes), estarão cadastrados em um outro banco de dados;

 

 

Quando o operador tentar acessar o sistema, executaria a seguinte lógica:

 

se (usuário (operador) existe no banco do cliente)

acessa o sistema

se (usuário (operador) existe no banco de operadores)

acessa o sistema

se não

erro

 

 

O que estou querendo mesmo saber é se isso é viável a nível de performance e também de código e tal. Alguém poderia me ajudar nisso ai?

Compartilhar este post


Link para o post
Compartilhar em outros sites

Por que necessariamente BANCOS diferentes? não pode ser simples tabelas?

 

Então Vinicius, seguinte:

Porque eu não acho legal tabelas, porque se o serviço tiver 1000 clientes, nosso banco de dados vai ficar muito grande, sem contar que eu teria que tá fazendo relacionamentos adoidados com cada cliente, e até pra manutenção ficaria ruim, por isso uma banco de dados pra cada cliente, pois o serviço é um gerenciador comercial.

Compartilhar este post


Link para o post
Compartilhar em outros sites

porque não uma coluna, faz igual a maioria

niveis de usuarios usando numero,

ex: se o nível de usuario é 100 ele pode acessar qualquer conta,

se 10 só é permitido a dele proprio e assim por diante,

quanto ao relacionamento fica tudo igual,

são todos pessoas (fisicas, juridicas, e colaboradores)

Compartilhar este post


Link para o post
Compartilhar em outros sites

 

sem contar que eu teria que tá fazendo relacionamentos adoidados com cada cliente, e até pra manutenção ficaria ruim, por isso uma banco de dados pra cada cliente, pois o serviço é um gerenciador comercial.

Acredito que um bom relacionamento entre as tabelas sai mais barato no futuro, só de pensar que teria de efetuar manutenção em 1000 bancos, já começa a sair caro.

 

1000 backups diários. :cry:

 

Add novas funcionalidades em 1000 bancos e subindo :huh:

 

while { :pinch: :pinch: :pinch: :pinch: :pinch: :pinch: :pinch: :pinch: :pinch: :pinch: ... }

Compartilhar este post


Link para o post
Compartilhar em outros sites

porque não uma coluna, faz igual a maioria

niveis de usuarios usando numero,

ex: se o nível de usuario é 100 ele pode acessar qualquer conta,

se 10 só é permitido a dele proprio e assim por diante,

quanto ao relacionamento fica tudo igual,

são todos pessoas (fisicas, juridicas, e colaboradores)

 

Wesley, essa sua solução nesse caso eu centralizaria as informações de usuário em um lugar só correto, e ai verificaria se o usuário está registrado e qual conta a ele pertence?

 

Williams te entendo, mas minha preocupação é o banco futuramente ficar muito grande e isso atrapalhar a performance da aplicação, e sem contar que pra cada tabela de dados teria que ter um relacionamento com o cliente, isso é de boa?

Compartilhar este post


Link para o post
Compartilhar em outros sites

Cara, quanto mais vc exigir do banco de dados mas vc tem a ganhar.

 

Pegue um banco de dados bom como oracle e você não terá problemas...

é claro você precisa crias as chaves corretamente, criar índice e saber dividir bem as tabelas.

 

O básico é

TABELA USUÁRIO
ID USERNAME PASSWORD GROUP

TABELA CLIENTE
ID NOME LOGIN

TABELA CLIENTE_X_USUARIO
USUÁRIO.ID, CLIENT.NOME

TABELA GRUPO
ID GROUP_NAME

TABELA DE APLICAÇÃO
ID APP_NAME

TABELA GRUPO_X_APLICAÇÃO
APLICAÇÃO.ID, GRUPO.ID


a lógica fica simples.

O grupo pode visualizar aplicações.
Exemplo:

Grupo ADM visualização aplicação
Adicionar usuário, Remover usuário

Um usuário do SEU sistema pertence a um GRUPO.
Usuário rogerio.baldan pertence ao grupo ADM
logo ele pode ver as aplicações Adicionar Usuário e remover usuário.

Um usuário do seu sistema enxerga quantos clientes do seu sistema?
ai é a tabela de relacionamento com o cliente.

isso é bem básico mas vá por esse caminho que é sucesso.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Um banco grande não é problema nenhum...

 

Mil bancos iguais sim, são mil problemas...

Compartilhar este post


Link para o post
Compartilhar em outros sites

É como Vinicius Rangel e William Bruno disse!

 

Também estou construindo um sistema SaaS um eMarketPlace e já estou programando para uns 100k de lojas e com diversas consultas e utilizando o MySQL a última versão.

 

Além dos relacionamentos entre as tabelas, também faço com tabelas de outros bancos, você não precisa colocar tudo em uma unica cesta "banco". Explore ao máximo triggers, procedures e etc.....

A ultima versão do navicat te permite fazer este relacionamento entre tabelas e bancos diferentes, mantendo total controle entre updates e deletes.

 

Depois é Oracle para aguentar o tranco e profissionais de DBAs.

 

PS.

Sobre performance!
É hardware mesmo, junto com um bom tunning.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Faça uma app de install =D

 

utilize a mesma para a criação de sua aplicação, sendo que seria semelhante a um CMS.

Teria ai, uma estrutura básica e varias pastas para cada diretório.

 

Primeiro problema seria, atualizações =D

Refazer em vários arquivos ex.

 

1000 clientes precisaria refazer em 1000 diretórios e update em 1000 bancos caso modifique alguma tabela no banco.

Ou somente em 1 cliente especifico usando a maneira de citei ou como deseja fazer.

 

 

mas, infelizmente teria link para o select no seu banco, =D

Pode ser como deseja, mas, recomento que utilize somente um banco.

Compartilhar este post


Link para o post
Compartilhar em outros sites

 

Então Vinicius, seguinte:

Porque eu não acho legal tabelas, porque se o serviço tiver 1000 clientes, nosso banco de dados vai ficar muito grande, sem contar que eu teria que tá fazendo relacionamentos adoidados com cada cliente, e até pra manutenção ficaria ruim, por isso uma banco de dados pra cada cliente, pois o serviço é um gerenciador comercial.

 

Cara, isto não faz muito sentido, porque 1000 clientes é um número extremamente baixo de registros, mesmo que existam outras ligações no sistema, é muito mais simples tanto de dar manutenção quanto para a consulta, que todos os clientes estivessem em um mesmo bando, por exemplo, uma tabela de clientes por empresa, aonde o ID da empresa é ligado em todas as tabelas do banco de dados, ou seja, tudo que está conectado no seu banco está relacionado e uma empresa e um cliente específico, ai você só não pode esquecer de, em todas as queries, usar o where <id empresa> = $_SESSION/$_POST/$_GET/$_COOKIE etc...

 

Imagina na quantidade de espaço em disco disponível você teria se tivesse que "fatiar" seu HD para diferentes bancos de dados...

Compartilhar este post


Link para o post
Compartilhar em outros sites

Tô entendendo. Estão me convencendo de que uma base de dados é mais interessante mesmo. Mas como o projeto ainda não tem grana para bancar um base de dados em Oracle, vocês acham que o MySql é interessante pra começar?

Compartilhar este post


Link para o post
Compartilhar em outros sites

Tô entendendo. Estão me convencendo de que uma base de dados é mais interessante mesmo. Mas como o projeto ainda não tem grana para bancar um base de dados em Oracle, vocês acham que o MySql é interessante pra começar?

 

Oracle é free. nas versões 11g. MySQL não tem muita robustez, se você sabe que seu sistema vai ficar muito grande ai não recomendo, PostGreSQL é uma boa pedida, está entre o oracle e o MySQL.

Compartilhar este post


Link para o post
Compartilhar em outros sites

No artigo que o Williams Duarte mencionou, na sessão do PostgreSQL, diz que:

 

Speed
If all you require is fast read operations, PostgreSQL is not the tool to go for

 

Até que ponto isso poderia acontecer? Quando eu tiver uma base de dados absurda?

Compartilhar este post


Link para o post
Compartilhar em outros sites

O que é absurdo para você?

 

Tenho clientes aqui na empresa que rodam em postgres, só de movimentação sobe mais de 100 mil por semana e até agora nenhum problema ocorreu.

 

Temos procedures, views e usamos tudo que o banco da direito e procuramos exigir menos da aplicação web.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Bom amigo, vai ter que estudar mais a respeito dos SGDBs, para evitar isso você pode trabalhar os pool de conexões.

Todos tem seus prós em contras, e o da Oracle o preço. :grin:

Compartilhar este post


Link para o post
Compartilhar em outros sites

No artigo que o Williams Duarte mencionou, na sessão do PostgreSQL, diz que:

 

Speed

If all you require is fast read operations, PostgreSQL is not the tool to go for

 

Até que ponto isso poderia acontecer? Quando eu tiver uma base de dados absurda?

 

Cara, tanto o postgres quanto o oracle, mysql e etc suportam bastante coisa rs

Compartilhar este post


Link para o post
Compartilhar em outros sites

×

Informação importante

Ao usar o fórum, você concorda com nossos Termos e condições.