Relacionamento (MySql)

7 respostas Resolvido
bancomysql
B

Olá Pessoal,

Estou tentando criar uma aplicação WEB onde todos os clientes compatilharão as mesmas tabelas, ou seja, haverá um banco de dados para vários clientes. Logo, eles utilizarão - entre si - as mesmas tabelas da instância do banco.

Entretanto, não sei a forma correta de fazer isso no banco para evitar conflitos e demais erros. Basicamente, cada cliente terá um cadastro único, porém poderá ter 1 ou vários usuários, bem como cada cliente poderá ter 1 matriz com 1 ou várias filiais.

Sabendo que haverá um ID único para cada cliente, e cada cliente poderá ter 1 ou vários usuários, eu entendo que todas as tabelas deverão conter a FK da tabela Cliente.

Resumo:
1º Dúvida: Melhor/Correta maneira de relacionar Tabela Cliente x Usuários x Matriz x Filial
2º Dúvida: Melhor/Correta maneira de relacionar demais tabelas do banco para cada cliente ou usuário

Agradeço qualquer ajuda. valeu

Tabelas e seus campos principais, bem como fk:

Clientes (com id unico)
id_cliente

Usuários (com id unico)
id_cliente (fk)

Matriz (com id unico)

Filial (com id unico)
id_matriz (fk)

7 Respostas

J

Você precisa realmente usar essa arquitetura de um único BD para “N” clientes distintos?

B

Sim jonathan. Porque o investimento inicial é baixo e não temos condições de ter um servidor parrudo pra aguentar mais de 1 estância, até porque serão muitas tabelas também para cada instância.

Quando falo instância de banco, me refiro ao schema. só pra não confudir muito, estou acostumado a chamar de instância…

valeu

J

Tranquilo eu compreendo pelos 2 termos.

Entendi a situação, eu digo isso por questões que agora não afetam mas futuramente podem vir a afetar, por exemplo pensando um cenário com 3 clientes em que cada um possua 5 filiais, já totalizam 15 lojas movimentando dados no banco, isso pode afetar de certa forma o desempenho do BD, controle de concorrência e locks de dados, possível perca de desempenho em querys conforme a massa de dados que está sendo movimentada, isso sem mencionar backup e restore, uma possível migração tanto de um cliente novo como a desistência de um cliente existente, e isso aumenta consequentemente de acordo com a quantidade de clientes que você movimentará.

Também tem que se pensar na quantidade de usuários simultâneos consumindo informações, imaginar também que você pode ter clientes que ocupam o seguinte cenário, 3 grupos econômicos cada um com “N” filiais, porém é um único cliente e eles compartilham dos mesmos dados.

Isso pode vir a se tornar um problema que custe alto futuramente para solucionar, por isso que te perguntei, de repente vale reconsiderar alguns pontos já no inicio para evitar transtornos futuros.

B

De fato Jonathan. Mas, infelizmente o cenário que eu gostaria não é possível. Acredito que a opção ideal seria ter de fato um bd pra cada cliente como vc citou em outras palavras.

Será aplicação web, então teremos clientes entrando e saindo toda hora. Se for 1 banco pra cada, talvez teria que ver essa questão no Java para disparar a criação de instância e isso levaria tempo, pois são várias tabelas. Este foi um ponto que pesou muito - além de outros - na tomada de decisão em ter apenas 1 instância de banco para todos os clientes. Se houver outra estratégia, desconheço…

De início, será permitido apenas 3 filiais por matriz e 2 usuários por cliente. De acordo com a evolução de infra que teremos junto a AWS, daremos maior margem de usuários conectados simultaneamente por cliente.

Com relação ao banco, como vc sugere nesse exemplo que mostrei?

J
Solucao aceita

Entendi, conforme a sua demanda dá pra ir analisando e modificando alguns pontos para melhoria!

No exemplo que você me mostrou eu colocaria o id do cliente na tabela matriz, o restante me parece estar legal.

Não sei no contexto geral da sua aplicação, mas talvez o uso do MongoDB seja legal e aplicável em alguns pontos, por se tratar de um DB não relacional isso já te dá um ganho de desempenho, ao menos para cadastros simples.

B

Legal Jonathan! Obrigado por enquanto. forte abraço

Caso queiram, podem encerrar o tópico!

valeu

J

O tópico só se dá por encerrado quando você marca uma resposta como solução, ou quando algum dos adm fecham o tópico.

Criado 16 de janeiro de 2019
Ultima resposta 16 de jan. de 2019
Respostas 7
Participantes 2