Unica pagina de login apontando para diferentes banco de dados MySQL

[Felipe Guedes Coutinho 0]

@luizfabri

 

Fera, desculpa a demorar para responder.

 

Antes de mais nada, o que você fez foi um POST de resposta em um Tópico, por isso fica complicado de alguém responder, recomendo você a abrir um TÓPICO para a sua pergunta.

 

Você deve definir a linguagem de programação ou problema relacionado.

 

Mas caso você voltei aqui para ver se responderam, vou tentar lhe ajudar, mas não responda aqui, crie um Tópico só seu, okay?

 

Então, vamos lá.

 

Você tem 2 Banco de Dados para 1 único Sistema? Eu não tenho o costume de pensar em Banco De Dados para registrar funcionalidades, o que eu tenho em mente foi o que comentei com @kelvinferraz, um Banco De Dados e N tabelas para cada funcionalidade.

 

O que eu recomendo você a fazer é o seguinte, já que você tem LEVEL DE ACESSO, eu recomendo você a mudar essa forma de Gerar Bases de Dados e apenas criar 1 tabela para conteudo, então, você faz na sua programação os SELECT utilizando o LEVEL DE ACESSO de cada usuário.

 

Exemplo, tabela de Login tem ID do usuário, LOGIN do usuário, SENHA do usuário e o LEVEL de acesso do usuário.

 

Na sua programação o que tiver o tal do S,A,C você faz os SELECT sem utilizar os ID para acessar a tabela de conteudo, assim trazendo todas as informações, como você precisa que esses 3 não acessem as informações do Coworking, basta além de você colocar na tabela de informação o ID do usuário que inseriu aquele registro, colocar também o LEVEL de acesso, e no select colocar para esses três S,A,C tudo diferente na coluna Level de Acesso de COWORKING, assim não terei acesso as informações do usuário COWORKING que colocou informação na base, e para o COWORKING fica mais fácil, faz o select na base de conteudo onde o ID deve ser igual ao ID do usuário COWORKING logado e o LEVEL igual ao do COWORKING, assim eu só terei acesso as informações desse USUÁRIO que tem LEVEL DE ACESSO COWORING, assim o seu sistema não precisa ficar gerando TABELAS nem BASE DE DADOS para cada usuário, o que fica completamente inviável.

 

Bom, é isso.

 

* PRECISO DE AJUDA - Vejá meu problema aqui Problemas com SELECT

 

Espero ter ajudado.

 

Att.

Felipe Coutinho

[kelvinferraz 0]

Em 30/08/2019 at 16:11, Felipe Guedes Coutinho disse:

@luizfabri

 

Fera, desculpa a demorar para responder.

 

Antes de mais nada, o que você fez foi um POST de resposta em um Tópico, por isso fica complicado de alguém responder, recomendo você a abrir um TÓPICO para a sua pergunta.

 

Você deve definir a linguagem de programação ou problema relacionado.

 

Mas caso você voltei aqui para ver se responderam, vou tentar lhe ajudar, mas não responda aqui, crie um Tópico só seu, okay?

 

Então, vamos lá.

 

Você tem 2 Banco de Dados para 1 único Sistema? Eu não tenho o costume de pensar em Banco De Dados para registrar funcionalidades, o que eu tenho em mente foi o que comentei com @kelvinferraz, um Banco De Dados e N tabelas para cada funcionalidade.

 

O que eu recomendo você a fazer é o seguinte, já que você tem LEVEL DE ACESSO, eu recomendo você a mudar essa forma de Gerar Bases de Dados e apenas criar 1 tabela para conteudo, então, você faz na sua programação os SELECT utilizando o LEVEL DE ACESSO de cada usuário.

 

Exemplo, tabela de Login tem ID do usuário, LOGIN do usuário, SENHA do usuário e o LEVEL de acesso do usuário.

 

Na sua programação o que tiver o tal do S,A,C você faz os SELECT sem utilizar os ID para acessar a tabela de conteudo, assim trazendo todas as informações, como você precisa que esses 3 não acessem as informações do Coworking, basta além de você colocar na tabela de informação o ID do usuário que inseriu aquele registro, colocar também o LEVEL de acesso, e no select colocar para esses três S,A,C tudo diferente na coluna Level de Acesso de COWORKING, assim não terei acesso as informações do usuário COWORKING que colocou informação na base, e para o COWORKING fica mais fácil, faz o select na base de conteudo onde o ID deve ser igual ao ID do usuário COWORKING logado e o LEVEL igual ao do COWORKING, assim eu só terei acesso as informações desse USUÁRIO que tem LEVEL DE ACESSO COWORING, assim o seu sistema não precisa ficar gerando TABELAS nem BASE DE DADOS para cada usuário, o que fica completamente inviável.

 

Bom, é isso.

 

* PRECISO DE AJUDA - Vejá meu problema aqui Problemas com SELECT

 

Espero ter ajudado.

 

Att.

Felipe Coutinho

Cara exatamente, isso resolveu meu problema, estou utilizando Laravel e esta exatamente como eu precisava, só estou com uma dúvida outra coisa, relacionada a BD que talvez seja o principal problema para eu entender a lógica de como deve ficar aplicação em si.

Seguinte eu tenho uma tabela produtos, nela ja possuo um user_id que é referenciada ao id da tabela users, porém quando eu cadastro esse produto eu queria poder validar que existe ja um produto cadastrado por exemplo como "nome ja cadastrado", eu estou tentando utilizar o que o Laravel tem disponível para validações como o 'nome_produto' =>  unique:produtos, porém como eu tenho essa situação de possuir vários usuários, eu teria que tentar amarrar outro id para o nome do produto? Porque dessa forma que eu fiz ele esta de fato validando e não deixa cadastrar 2 produtos com mesmo nome, mas como cada usuário tem o seu user_id nas tabelas como me informou, eu não consigo validar no campo só desse usuário, "ou ainda não sei fazer isso no laravel, se souber e puder me ajudar seria 1000!!".

Abraçoo

[Felipe Guedes Coutinho 0]

@kelvinferraz

 

Simples, se você quer saber se existe um produto cadastrado na tabela antes de INCLUIR, basta você fazer um SELECT na tabela passando no WHERE o campo que quer buscar e o valor que você IRA tentar INCLUIR, se achar, BINGO você já tem o produto cadastrado e ai faz uma coisa, se não achar BINGO DE NOVO, você vai lá e incluir.

 

Basta você pensar na REGRA do que não pode acontecer.

 

Exemplo, EU (um usuário) quero incluir o produto CHAVE DE FENDA ai vem a regra, se já existir uma CHAVE DE FENDA na base eu não posso incluir, OU se já existe uma CHAVE DE FENDA QUE EU JÁ INCLUI UMA VEZ, então não posso incluir de novo, é você que tem que decidir qual é a regra.

 

Para as duas regras exemplos que eu coloquei ai em cima a diferença fica no WHERE.

 

PARA ESTE EXEMPLO: "EU (um usuário) quero incluir o produto CHAVE DE FENDA ai vem a regra, se já existir uma CHAVE DE FENDA na base eu não posso incluir" O meu SELECT fica assim:

 

SELECT * FROM TABELA WHERE NOME_PRODUTO = "CHAVE DE FENDA";

 

Se encontrar qualquer CHAVE DE FENDA o item existe.

 

PARA O OUTRO EXEMPLO: "OU se já existe uma CHAVE DE FENDA QUE EU JÁ INCLUI UMA VEZ, então não posso incluir de novo" O meu SELECT fica assim:

 

SELECT * FROM TABELA WHERE NOME_PRODUTO = "CHAVE DE FENDA" AND ID_USUARIO = 1;

 

1 é o meu ID na tabela de usuário.

Então se eu achar CHAVE DE FENTA com o MEU USUÁRIO então já existe um produto que eu INCLUI na tabela.

Então faça a sua regra e adapte para que você obtenha o resultado desejado.

 

Espero ter ajudado.

 

Att.

Felipe Coutinho

 

[kelvinferraz 0]

Obrigado!

 

Já deu para entender!!