ESTRUTURA DE DADOS DUVIDA LOGIN
Bom dia.
Estou implementando um novo projeto com uma estrutura diferene que inclui empresas acima dos departamentos:
Tab_Empresas(ID,RazaoSocial,CNPJ, etc....)
Tab_Departamentos(ID,ID_Empresa, NomeDepto)
Tab_Funcionarios(ID, ID_Departamentos, Matricula, etc....)
Cenário para Entender
- A empresa usuário do sistema, pode ter grupos associados, outra empresas (CNPJs). Então poderia utilizar o sistema das seguintes forma:
1- Tudo centralizado num único banco, várias empresas do grupo acessando todos os dados, umas das outras.
2- Cada empresa acessando somente seus dados, tudo num único banco, mas sem visibilidade entre elas, somente o gestor do sistema poderia ver tudo.
3- Cada empresa com sua estrutura independente, um banco para cada empresa, que pode ser no mesmo servidor central ou em servidores diferentes.
Com isso surgiu as seguintes dúvidas:
1- Ao se logar no sistema, o usuário fica obrigado a selecionar a empresa e entrar usuário e senha. Porém há probabilidade de que ocorra dois usuários com mesmo nome de usuário (em empresas diferentes), e que por [Ô]AZAR[Ô] usem a mesma senha. Como se poderia resolver isso, pois não dá para impedir o cadastro de um usuário em uma empresa, porque existe o mesmo em outra. Também não se pode impedir o uso da mesma senha, pois o usuário saberia na hora a senha do outro. Como se pode resolver isso?
2- Nesse cenário, em cada registro cadastrado, seria sempre obrigatório a inclusão inicial da empresa / departamento / usuário, em função da escolha da empresa o sistema localizaria todos os seus departamentos, e selecionado um departamento, o sistema localizaria, em função do tipo de cadastro realizado, ou todos os funcionários da empresa ou só do departamento selecionado. O problema aqui é com a estrutura definida pela empresa, ou seja, se ela tiver tudo centralizado ok, pois sempre seria preciso escolher a empresa que se deseja cadastrar o registro. Porém no caso das empresas que optarem por não permitir a visualização entre elas, ou que tudo fica totalmente separado (banco individual por empresa do grupo ou no caso de empresas que não possuam outra, sejam únicas), todos os cadastros traram sempre o campo EMPRESA para seleção que seria desnecessário. Não sei se seria a melhor solução, pois ainda não vi isso na prática com a OOP, mas ao iniciar o sistema faria uma pesquisa no banco para ver se há mais de uma empresa cadastrada, se existir somente uma, eu automaticamente setaria ela no campo empresa e manteria Enabled nesse campo para não ser alterado, isso evitaria do usuário ter esse trabalho. Porém não sei se haveria outras implicações que ainda não pensei.
Estou implementando um novo projeto com uma estrutura diferene que inclui empresas acima dos departamentos:
Tab_Empresas(ID,RazaoSocial,CNPJ, etc....)
Tab_Departamentos(ID,ID_Empresa, NomeDepto)
Tab_Funcionarios(ID, ID_Departamentos, Matricula, etc....)
Cenário para Entender
- A empresa usuário do sistema, pode ter grupos associados, outra empresas (CNPJs). Então poderia utilizar o sistema das seguintes forma:
1- Tudo centralizado num único banco, várias empresas do grupo acessando todos os dados, umas das outras.
2- Cada empresa acessando somente seus dados, tudo num único banco, mas sem visibilidade entre elas, somente o gestor do sistema poderia ver tudo.
3- Cada empresa com sua estrutura independente, um banco para cada empresa, que pode ser no mesmo servidor central ou em servidores diferentes.
Com isso surgiu as seguintes dúvidas:
1- Ao se logar no sistema, o usuário fica obrigado a selecionar a empresa e entrar usuário e senha. Porém há probabilidade de que ocorra dois usuários com mesmo nome de usuário (em empresas diferentes), e que por [Ô]AZAR[Ô] usem a mesma senha. Como se poderia resolver isso, pois não dá para impedir o cadastro de um usuário em uma empresa, porque existe o mesmo em outra. Também não se pode impedir o uso da mesma senha, pois o usuário saberia na hora a senha do outro. Como se pode resolver isso?
2- Nesse cenário, em cada registro cadastrado, seria sempre obrigatório a inclusão inicial da empresa / departamento / usuário, em função da escolha da empresa o sistema localizaria todos os seus departamentos, e selecionado um departamento, o sistema localizaria, em função do tipo de cadastro realizado, ou todos os funcionários da empresa ou só do departamento selecionado. O problema aqui é com a estrutura definida pela empresa, ou seja, se ela tiver tudo centralizado ok, pois sempre seria preciso escolher a empresa que se deseja cadastrar o registro. Porém no caso das empresas que optarem por não permitir a visualização entre elas, ou que tudo fica totalmente separado (banco individual por empresa do grupo ou no caso de empresas que não possuam outra, sejam únicas), todos os cadastros traram sempre o campo EMPRESA para seleção que seria desnecessário. Não sei se seria a melhor solução, pois ainda não vi isso na prática com a OOP, mas ao iniciar o sistema faria uma pesquisa no banco para ver se há mais de uma empresa cadastrada, se existir somente uma, eu automaticamente setaria ela no campo empresa e manteria Enabled nesse campo para não ser alterado, isso evitaria do usuário ter esse trabalho. Porém não sei se haveria outras implicações que ainda não pensei.
Bom, já lidei com um sistema onde o mesmo sistema atendia 3 estabelecimentos: 1 matriz e 2 filiais. E a abordagem de cada empresa ter seu sistema e banco isolado mostrou ser a melhor forma, pois evita regras intricadas no código pra poder atender certos requisitos, os sistemas de filiais diferentes podiam evoluir suas próprias necessidades sem comprometer outras filiais, isso tanto no que tange a código quanto a modelagem do banco de dados. O bom era que o dono das empresas usava o módulo financeiro e de compras com as 3 instâncias abertas ao mesmo tempo, fazendo comparativos, respondendo a clientes, atendendo fornecedores, passando instruções aos gerentes e etc.
Antes de lidar com esse sistemas não acreditaria que essa abordagem seria a melhor, mas na prática mostrou ser, quanto mais as filias forem de cidades diferentes.
Antes de lidar com esse sistemas não acreditaria que essa abordagem seria a melhor, mas na prática mostrou ser, quanto mais as filias forem de cidades diferentes.
Então nas empresas que trabalhei a estrutura de dados era mais ou menos a que você sugeriu.
O usuário informava [Ô]Usuário, senha e estabelecimento[Ô], era uma base de dados única.
Cada usuário com o seu perfil, o perfil de ADM visualizava tudo mas somente daquele estabelecimento.
Em relação ao usuário é complicado o ideal seria trabalhar com o Active Directory mas não ter o mesmo usuário.
O usuário informava [Ô]Usuário, senha e estabelecimento[Ô], era uma base de dados única.
Cada usuário com o seu perfil, o perfil de ADM visualizava tudo mas somente daquele estabelecimento.
Em relação ao usuário é complicado o ideal seria trabalhar com o Active Directory mas não ter o mesmo usuário.
Leandro meu sistema é único e não personalizado, ou seja, só tem uma versão para todos os clientes. Não é um ERP, mas uma ferramenta especÃfica, onde isso é possÃvel por se tratar de normatização. Sendo assim se a estrutura de um cliente é de múltiplas empresas, tenho de atender, pois a versão atual não contempla isso e perdi clientes.
ALEVALE não entendi
Achar um usuário associado a uma empresa, isso é fácil, o que estou em dúvida é saber como evitar um problema de ter dois usuários iguais e até com senhas iguais em empresas diferentes. Gravar eu sei, pois faria um teste se já existe esse usuário nesta empresa, mas suponhando que um usuário use seu usuário e senha em outra empresa, se existir ele teria acesso a tudo nesta empresa, e isso não é possÃvel. Claro que é um caso difÃcil de acontecer, mas não impossÃvel. Pois existem tantos homônimos, que coincider o usuário e senha não é tão inviável assim.
ALEVALE não entendi
Citação:Em relação ao usuário é complicado o ideal seria trabalhar com o Active Directory mas não ter o mesmo usuário.
Achar um usuário associado a uma empresa, isso é fácil, o que estou em dúvida é saber como evitar um problema de ter dois usuários iguais e até com senhas iguais em empresas diferentes. Gravar eu sei, pois faria um teste se já existe esse usuário nesta empresa, mas suponhando que um usuário use seu usuário e senha em outra empresa, se existir ele teria acesso a tudo nesta empresa, e isso não é possÃvel. Claro que é um caso difÃcil de acontecer, mas não impossÃvel. Pois existem tantos homônimos, que coincider o usuário e senha não é tão inviável assim.
Citação:ALEVALE não entendi
Citação:
Em relação ao usuário é complicado o ideal seria trabalhar com o Active Directory mas não ter o mesmo usuário.
Você poderia ter uma tabela que ao invés de você criar os usuários manualmente, você poderia incluir o usuário mas se baseando no Active Directory, mas de qualquer forma teria uma tabela de usuários.
Você iria criar o usuário mas iria selecionar o mesmo dentro de um Active Directory.
Ou melhor poderia ter a opção [Ô]FILTRAR NO ACTIVE DIRECTORY[Ô] no qual você iria incluir o usuário que já está cadastrado na rede ou ter a opção [Ô]MANUAL[Ô] que você iria informar o usuário e depois de informado você verificar na base de dados se o usuário já existe.
Citação::
Leandro meu sistema é único e não personalizado, ou seja, só tem uma versão para todos os clientes. Não é um ERP, mas uma ferramenta especÃfica, onde isso é possÃvel por se tratar de normatização. Sendo assim se a estrutura de um cliente é de múltiplas empresas, tenho de atender, pois a versão atual não contempla isso e perdi clientes.
Vixiii .. então é imprescindÃvel esse requisito.
Acho que vc resolve, não permitindo registrar usuário com um nome que já exista vinculado em qualquer outra empresa. Se formos fazer uma analogia com um domÃnio de rede, é praticamente o que vc tem aà só que em vez de ser por domÃnio do negócio do cliente. Vc não pode ter dois usuários com o mesmo nome em um domÃnio de rede, mas usuários de um mesmo domÃnio tem permissões e acessibilidades distintas dentro do domÃnio. Digamos que dentro do domÃnio do seu cliente, vc tem seções ou regiões que são empresas e por consequência suas funcionalidades, que são acessÃveis somente com permissão concedida pelo gerente do domÃnio.
Acho que é uma abordagem mais fácil e plausÃvel. Vamos ver o que os colegas tem a dizer.
Bem fui ler sobre o Active Directory que comentou. A princÃpio não vejo isso como solução do meu problema, e nem como seria possÃvel integrar isso, uma vez que esse serviço é ferramenta de REDE da Microsoft e no meu caso, o acesso é local do meu aplicativo, sendo que pode haver (n) servidores no cliente, um para cada empresa usuário do sistema, onde o banco de dados estaria em um servidor a parte só para isso. Sendo assim, ainda há outras situações, como meu sistema ser instalado no servidor para acesso remoto ou localmente em cada micro. Com isso poderia ocorrer (n) situações complicadas, pois o Login é no meu sistema e não na rede ou redes do cliente. Se o cliente tiver vários servidores, só unificando o de banco de dados, complicaria ainda mais.
Além disso, supondo que houvesse um único servidor, uma única rede para tudo, ainda assim a permissão de acesso deveria ser dada igualmente para ambos os usuários no meu sistema e com isso o acesso a ele geraria o mesmo problema, pois ao entrar o login e senha a redundância permaneceria, ou seja, havaria a possibilidade de um entrar no login do outro se descobrissem.
Uma outra situação que me impede de seguir nessa linha, nem sei se seria viável, é que cada clientes possui uma estrutura de rede diferente, e isso seria um complicador, pois como disse, meu sistema é único e não individualizado. Assim não há como tratar cada caso individualmente, ele tem que ser um padrão que funcione para qualquer cliente, independente de ter um recurso especÃfico ou não de rede configurado.
Nota: Isso tudo me fez refletir sobre um outro grande problema, o licenciamento do sistema. Hoje eu pratico a licença por CNPJ e não por usuário ou micro. Cada empresa tem seu licenciamento especÃfico, pois o sistema só permite uma empresa por licença. Há a opção de incluir novas licenças, nesse caso cada micro tem que ser configurado para setar uma única empresa, não podendo acessar a outra. O que estou tentando idealizar é uma opção onde um usuário de uma empresa possa acessar seus dados, estando na outra empresa do grupo, o que ocorre muito na prática para alguns seguimentos ou funções de funcionários.
Nesse sentido vem a grande dúvida, pois se eu posso ter um cliente (Consórcio) com uma única licença, mas que tenha duas ou mais empresas no consórcio, é necessário que haja o cadastro de todas as empresas para o acesso por cada funcionário, exemplo construtoras. Porém como eu faria para identificar se o software esta devidamente licenciado, sendo que há só uma licença, mas (n) empresas cadatradas?
Como o sistema é único, analisando agora a situação de outra empresa (um grupo com n empresas), onde cada empresa terá sua própria licença de uso, porém tudo interligado num único banco, fica mais fácil, pois bastaria saber se a empresa possui uma licença cadastrada. O problema é como gerenciar o licenciamento multiplo num mesmo software.
A coisa ficou bem complicada agora.
Além disso, supondo que houvesse um único servidor, uma única rede para tudo, ainda assim a permissão de acesso deveria ser dada igualmente para ambos os usuários no meu sistema e com isso o acesso a ele geraria o mesmo problema, pois ao entrar o login e senha a redundância permaneceria, ou seja, havaria a possibilidade de um entrar no login do outro se descobrissem.
Uma outra situação que me impede de seguir nessa linha, nem sei se seria viável, é que cada clientes possui uma estrutura de rede diferente, e isso seria um complicador, pois como disse, meu sistema é único e não individualizado. Assim não há como tratar cada caso individualmente, ele tem que ser um padrão que funcione para qualquer cliente, independente de ter um recurso especÃfico ou não de rede configurado.
Nota: Isso tudo me fez refletir sobre um outro grande problema, o licenciamento do sistema. Hoje eu pratico a licença por CNPJ e não por usuário ou micro. Cada empresa tem seu licenciamento especÃfico, pois o sistema só permite uma empresa por licença. Há a opção de incluir novas licenças, nesse caso cada micro tem que ser configurado para setar uma única empresa, não podendo acessar a outra. O que estou tentando idealizar é uma opção onde um usuário de uma empresa possa acessar seus dados, estando na outra empresa do grupo, o que ocorre muito na prática para alguns seguimentos ou funções de funcionários.
Nesse sentido vem a grande dúvida, pois se eu posso ter um cliente (Consórcio) com uma única licença, mas que tenha duas ou mais empresas no consórcio, é necessário que haja o cadastro de todas as empresas para o acesso por cada funcionário, exemplo construtoras. Porém como eu faria para identificar se o software esta devidamente licenciado, sendo que há só uma licença, mas (n) empresas cadatradas?
Como o sistema é único, analisando agora a situação de outra empresa (um grupo com n empresas), onde cada empresa terá sua própria licença de uso, porém tudo interligado num único banco, fica mais fácil, pois bastaria saber se a empresa possui uma licença cadastrada. O problema é como gerenciar o licenciamento multiplo num mesmo software.
A coisa ficou bem complicada agora.
Leandro se realmente não houver nenhuma outra solução conhecida (sugerida), essa é a opção que vejo, apesar de não ser a mais interessante, apesar de ser totalmetne lógica. Segundo essa visão, que foi a única que me passou também, é uma analogia para endereços eletrônicos ou número de telefone, onde não há dois números iguais ou dois emails iguais. Pode ocorrer u nick igual, mas o @.... é diferente ou nos telefones, há os prefixos que distinguem as cidades, estados e paÃses. Pode ser uma argumentação correta para incluir essa restrição.
===============
Se não houver uma solução [Ô]mágica[Ô] diferente, irei adotar essa mesma.
===============
Agora alguém teria uma idéia de como gerir o problema de licenciamento nesse cenário que passei?
===============
Se não houver uma solução [Ô]mágica[Ô] diferente, irei adotar essa mesma.
===============
Agora alguém teria uma idéia de como gerir o problema de licenciamento nesse cenário que passei?
Em relação ao Active Directory, você iria somente [Ô]selecionar[Ô] o usuário dentro do AD a forma de criação é a mesma.
São situações diferentes.
A ideia de selecionar um usuário dentro do Active Directory é simples, imagine que o funcionário [Ô]João da Silva[Ô] cujo usuário é [Ô]JSILVA[Ô], ao criar um usuário novo dentro do seu sistema você terá que criar o usuário correto !?
Então ai a questão, presumo que os valores para cadastrar um usuário novo sejam básicos (NOME, USUARIO,SENHA,ESTABELECIMENTO)
No campo NOME DO USUÃRIO você iria apenas selecionar o usuário dentro da Base do Active Directory, pois ao inveis de criar o usuário do [Ô]João[Ô] como JSILVA, você criou como [Ô]JOSILVA[Ô], entendeu ?
Apenas para facilitar o processo, não é em relação a Integração com o Active Directory para autenticação !
Mesmo assim a ideia seria a mesma, ao invés de selecionar o usuário, você pode muito bem cria-lo manualmente [Ô]DIGITANDO[Ô] o nome do usuário.
Existe a possibilidade de criar usuários iguais ! SIM
Mas para isso você terá que criar um ID para o mesmo, assim como o estabelecimento será diferente.
Dentro de uma mesma empresa NUNCA peguei o caso de ter o mesmo usuário com o mesmo nome.
Entendeu agora ?
Em relação a licença você pode criar o seu sistema por modulo também, assim você terá uma tabela com o modulo X empresa.
e talvez data de licença, assim ao acessar o sistema daquela empresa você verificar a licença se está válida ou não.
Agora uma forma de segurança de como gerar chave, validar etc... não sei como dizer..
São situações diferentes.
A ideia de selecionar um usuário dentro do Active Directory é simples, imagine que o funcionário [Ô]João da Silva[Ô] cujo usuário é [Ô]JSILVA[Ô], ao criar um usuário novo dentro do seu sistema você terá que criar o usuário correto !?
Então ai a questão, presumo que os valores para cadastrar um usuário novo sejam básicos (NOME, USUARIO,SENHA,ESTABELECIMENTO)
No campo NOME DO USUÃRIO você iria apenas selecionar o usuário dentro da Base do Active Directory, pois ao inveis de criar o usuário do [Ô]João[Ô] como JSILVA, você criou como [Ô]JOSILVA[Ô], entendeu ?
Apenas para facilitar o processo, não é em relação a Integração com o Active Directory para autenticação !
Mesmo assim a ideia seria a mesma, ao invés de selecionar o usuário, você pode muito bem cria-lo manualmente [Ô]DIGITANDO[Ô] o nome do usuário.
Existe a possibilidade de criar usuários iguais ! SIM
Mas para isso você terá que criar um ID para o mesmo, assim como o estabelecimento será diferente.
Dentro de uma mesma empresa NUNCA peguei o caso de ter o mesmo usuário com o mesmo nome.
Entendeu agora ?
Em relação a licença você pode criar o seu sistema por modulo também, assim você terá uma tabela com o modulo X empresa.
e talvez data de licença, assim ao acessar o sistema daquela empresa você verificar a licença se está válida ou não.
Agora uma forma de segurança de como gerar chave, validar etc... não sei como dizer..
Alevale o problema não é ter o mesmo usuário na mesma empresa, mas sim em empresas diferentes dentro do mesmo GRUPO, isso é possÃvel pois a Empresa A e B podem ter cada uma o funcionário Jão da Silva (nome super comum no Brasil) e em cada empresa criarem o login em suas redes de JSilva, e por analogia no meu sistema também ficar JSilva. Então como o meu sistema pode ter a opção de interagir com multiplas empresas, teria a situação de ter dois Usuários com mesmo nome e se por [Ô]Azar[Ô] ambos escolherem a mesma senha (difÃcil mas não impossÃvel), um poderia acessar os dados do outro e vice-versa.
Acho que a forma mais fácil e talvez eficaz, seja mesmo impedir dois usuários iguais no mesmo banco de dados. Com isso fica impossÃvel alguém acessar os dados de outro.
Acho que a forma mais fácil e talvez eficaz, seja mesmo impedir dois usuários iguais no mesmo banco de dados. Com isso fica impossÃvel alguém acessar os dados de outro.
Tópico encerrado , respostas não são mais permitidas