Multiempresa - Qual a Melhor Maneira?

Ola valdirdill, boa tarde.

Aqui na empresa usamos este tipo de estrutura.

mas acredito que você deva analisar a possibilidade de se trabalhar com filiais (por exemplo em uma base distribuida geograficamente).

Com empresa/filial você teria por exemplo um melhor gerênciamento das informações, como qual empresa/filial tem maior estoque, qual vende mais, qual tem mais inadimplência, etc.


[]´s

Oi,
Obrigado pela resposta.

Tenho certeza se entendi bem. Você diz que no seu programa você usa a sistemática que eu mencionei, é isso?
Se é isso, por favor, me diga se você conhece a solução para a seguinte situação: num cadastro - produtos por exemplo, quero cadastrar o produto ´Parafuso´ com o código 1 em duas empresas. No cadastro de produtos, o campo ´Codigo´ é chave. Como eu poderia fazer isso?

há sistemas feitos da forma como você exemplificou e há também aqueles com tabelas diferenciadas por empresa e dentro das tabelas a filial.
sendo prefixo + empresa.
por exemplo:
tabela de estoque:
prefixo: EST
estrutura:
Filial, Produto, Saldo

empresas (exemplo com 3 dígitos, podendo ter até 999 empresas):
001 - Extra
002 - Pão de açucar
003 - Barateiro

então haveria 3 tabelas distintas:
EST001 -> estoque da empresa 001
EST002 -> estoque da empresa 002
EST003 -> estoque da empresa 003
e assim por diante, e cada tabela contendo o movimento das filiais daquela empresa.

Ola.

Isso mesmo ja fazemos uso do metodo mencionado por voce.


Em relação ao cadastro do produto.

Se a chave é o codigo, voce tem que incluir o codigo da empresa na chave do produto.

Ai voce pode fazer de duas maneiras, na hora de salvar perguntar em qual outra empresa o usuario quer incluir o produto, ou deixar uma opção de menu para que ele faça copia de produtos determinados(uma seleção de faixa por exemplo). Eu particularmente usaria as duas(mas sendo uma unica rotina.

[]´s

Olá.

Após ler o que o colega emerson.en indicou,

Em caso da separação das tabelas ha depender do volume de dados obtem-se uma melhor performance, mas com certeza uma codificação mais detalhada para o acesso as informações.

Acredito que muitas outras maneiras e metodos existam.

Ver aqui outros casos de uso seria bacana.


[]´s

Caro amigo.

codifiquei da seguinte maneira, todas as tabelas possuem um campo filial, exe: clientes, funcionarios, usuários, contas à receber, contas à pagar, caixa e bancos etc. semente a tabela de produtos é dividida em duas. uma com o codigo, descrição, aplicação, similares, grupo, marca etc... outra com o código, filial, estoque, ultima venda, curva etc...
uma obs. vc pode parametrizar para que a empresa utilize o preço de venda igual ou diferenciado das outras lojas, vc pode ter a curva por por estoque de cada empresa e por todo o estoque etc...

espero ter ajudado.

Caro amigo.

codifiquei da seguinte maneira, todas as tabelas possuem um campo filial, exe: clientes, funcionarios, usuários, contas à receber, contas à pagar, caixa e bancos etc. semente a tabela de produtos é dividida em duas. uma com o codigo, descrição, aplicação, similares, grupo, marca etc... outra com o código, filial, estoque, ultima venda, curva etc...
uma obs. vc pode parametrizar para que a empresa utilize o preço de venda igual ou diferenciado das outras lojas, vc pode ter a curva por por estoque de cada empresa e por todo o estoque etc...

espero ter ajudado.

[b:e6d336dc9b]Emerson.en[/b:e6d336dc9b] com toda a sua experiência, qual é o modelo mais indicado para essa situação, pois já usei da forma como o colega descreveu no inicio do tópico. Gostaria de saber sua opnião e se possível informando os prós e contras de cada modelo.

valew!

Todas as metodologias mencionadas são aceitaveis, mas gostaria de chamar sua atenção para um problema que poucos dão importância, até que um dia o banco da problema.

Trata-se do chamado inchaço do banco de dados.

Vc precisa ter uma sistematica de limpeza e manutenção do banco de dados muito boa, pois colocar todas as empresas e filiais dentro do mesmo banco causa um crescimento acelerado do mesmo.

Dai, se vc tem certeza que o banco não vai crescer exageradamente, td bem, caso contrario eu sugeriria que vc cria-se um banco novo pra cada empresa (poderia até usar o cnpj de cada uma como nome do banco) e o seu sistema apresenta-se uma relação das empresas existentes ao ser carregado e ao escolher direcionaria o database ou dbconnection para o banco selecionado.

quase nenhuma experiência, na verdade...

mas posso dizer o seguinte: visando organização e facilidade na ´filtragem´ dos dados, o modelo separado por tabelas é um tanto satisfatório. seria um campo a menos para guardar (empresa não precisa ser informado, pois está subentendido no nome da tabela - isso pode até ser considerado bobagem nos dias de hoje, quando os HD têm gigabytes de capacidade, mas poderia economizar um bom espaço). também no caso de dados corrompidos - mesmo que atualmente isso seja um tanto raro (pra isso há o bkp), ainda acontece - esse modelo pode garantir melhor as informações: supondo que haja dano na tabela de pedidos, por exemplo, poderão ocorrer riscos de danos nos dados de [b:eeb0e92d47]uma[/b:eeb0e92d47] empresa, mas em tabela única [b:eeb0e92d47]todos[/b:eeb0e92d47] os dados estarão comprometidos. dependendo do sistema isso não é lá muita vantagem: um usuário pode estar logado numa empresa e outros em outras, pondo em ´risco´ todos os dados; há ainda o caso de tabelas superpopuladas, onde esse modelo pode trazer melhor performance, pois os dados estarão distribuídos, gerando índices menores e varredura mais rápida (dependedo do servidor e do seu HD, esse ganho pode ser imperceptível).
pode haver problemas com stored procedures e triggers, que em alguns casos têm de ser refeitas tantas vezes quanto haja empresas. se não houver manutenção nesses recursos, tudo bem, mas caso haja alguma alteração em trigger, por exemplo, poderá haver necessidade de [i:eeb0e92d47]n[/i:eeb0e92d47] alterações.

no caso de tabela única basta parametrizar o where e o problema está resolvido. creio que perca - supostamente - para o outro modelo em performance (disto dependerão queries parametrizadas e índices bem montadas), mas não haverá duplicidade de stored procedures/triggers.

eu trabalho com o modelo de tabela única, filtrando por campo empresa, filial e unidade.

p.s.: só pra constar, a microsiga utiliza o modelo de tabelas separadas por empresa.

p.s 2: pode-se ainda criar um banco de dados para cada empresa, mas isso pode representar um problema caso as empresas pertençam à um mesmo grupo: alguns RDBMS não suportam selects entre tabelas de bancos diferentes. com isso um grupo de supermercados, por exemplo, teria de duplicar, triplicar sua tabela de produtos, clientes, etc, o que é desnecessário, visto que meu CPF é único no Brasil, todas as empresas desse grupo deveriam obter as informações a meu respeito de um único local e, ao atualizar qualquer informação, a mesma deveria ser vistal por todos. seria necessário criar um mecanismo para evitar esse problema.

é necessário analisar: cada caso é um caso.

valew pelos esclarecimento [b:b49a836298]emerson.en[/b:b49a836298].

Bom FDS! :D