Firebird - Acesso Remoto

|Isto realmente vai acontecer?

Bom, pode ou não acontecer, depende da ´implementação´ do sistema -- para q não ocorra, vc terá de::

1- aplicar bem os conceitos C/S e utilizar corretamente o Firebird
2- dimensionar corretamente o hardware e recursos de rede
3- opcionalmente, utilizar um ´túnel seguro´ para compactação do tráfego de rede


|se eu fizer todas as lojas trabalharem com o mesmo banco vai ficar
|lento o sistema?

Não necessariamente. Veja a questão acima!

Outra opção q vc tem é ter servidores em cada ´filial´ replicando para um servidor principal na matriz (mas depende realmente das necessidades do sistema)


|E minha idéia sobre o CODIGO_FILIAL o que vcs acham ... é válida?

Ao meu ver É (mas não sei se tenho os detalhes necessários para avaliar)



T+

afarias valew por ter respondido
em sua observação em implementação do sistema vc disse em aplicar bem os conceitos C/S e ultilizar corretamente o Firebird ... vc tem algum matérial onde eu possa colher algumas dicas do que fazer e do que não fazer usando o Firebird ???

vc disse tambem que eu poderia utilizar um ´tunel seguro´ pesquisando por este termo acabei encontrando algo sobre zebedee e stunel qual dos dois é melhor na sua opinião??

Quanto ao hardware acho que nao vou ter muitos problemas pois todas as maquinas serão novas ...

vc tambem disse que eu poderia ter servidores nas filiais para replicar os dados para a matriz ... como eu deveria cuidar das chaves primarias ?? por exemplo na filial 01 foi cadastrado um cliente ou pedido com codigo 10 e na filial 02 tambem vai ter um cliente ou pedido de codigo 10 ... isso pode dar problema!!!

vc disse que nao tinha detalhes para poder avaliar o CODIGO_FILIAL .. pensei mais ou menos assim ... cada filial vai ter um cadastro e um código definido na hora da instalação do programa ... na tabela TB_CLIENTES eu coloco um campo COD_FILIAL dai quando uma determinada filial for cadastrar um cliente alem de todos os dados do cliente tambem vai entrar no campo citado o código da filial ... e este procedimento será adotado para toda inclusao de dados no banco de dados ... dai por exemplo quero fazer uma pesquiza:

select razao from tb_clientes where (razao = :razao) and (cod_filial = :cod_filial)
select pedido from tb_pedidos where (pedido = :pedido) and (cod_filial = :cid_filial)
select item form tb_pedidos_itens where (pedido = :pedido) and (cod_filial = :cod_filial)

bom afarias minha idéia sobre o COD_FILIAL FOI ESTA.

entao .... tentei expressar minhas duvidas, se vc puder me ajudar mais uma vez?

valewww

vou me intrometer um pouco:

quanto à colocação do nosso colega afarias, acho que ele está totalmente certo. quando ele fala sobre ´utilizar corretamente os conceitos de C/S (client/server)´, significa que você deve trafegar pela rede somente o necessário, não importando se isso é via internet ou rede local. segundo o conceito client/server você nunca deve abrir uma tabela antes de solicitar um registro ao cliente.

por exemplo: se vc vai abrir o cadastro de clientes, não abra a tabela (ela pode conter centenas de registros). motivos:
- se o usuário for incluir um novo cliente, qual a necessidade dele saber quais estão cadastrados? nenhuma! será um desperdício de tempo e de recursos da máquina/rede trafegar esses dados.
- se o usuário estiver procurando um cliente, com certeza ele sabe alguma informação do cliente: nome, cnpj, endereço... então ele vai buscar o cliente a partir dessa informação, sendo desnecessário abrir a tabela trazendo todos os registros, o que também desperdiçaria tempo e recursos da máquina/rede.
- entre outros...

quanto à implementação de FILIAL, isso é totalmente válido, mas não para clientes. clientes devem ter um cadastro único, pois há códigos (cnpj/cpf) que os diferenciam nacionalmente. imagine que vc faz uma compra nas Casas Bahia de Guarulhos (tem em qualquer lugar do Brasil). se vc aparecer nas Casas Bahia de Salvador, vão saber quem é vc devido ao CPF ser único, independente da filial onde vc foi cadastrado.

você precisa avaliar também o cadastro de produtos (se houver um). acontece que, dependendo da empresa, as filiais comercializam produtos diferenciados (na maioria das empresas as filiais comercializam os mesmos produtos).
- no caso de empresas onde as filiais tem produtos diferentes, o melhor é cada uma ter seu próprio cadastros de produtos. isso é um pouco complicado de gerenciar, mas torna o sistema um pouco mais seguro, pois um dano no cadastro de produtos de uma filial não impediria as outras de trabalharem.
- no caso filiais que comercializam os mesmos produtos, esse cadastro deve ser único.

com certeza você deve ter a Filial em orçamentos, pedidos, notas fiscais, recibos, cheques emitidos, titulos a pagar e a receber, saldo de produtos em estoque, etc.

basicamente é isso. qualquer coisa, tamos aí!

t+

emerson.en valew pelo seu comentário

O que vc e o afarias disseram foi de muita ajuda para mim ...

Quanto as dicas que vc me passou concordo com elas ... Esta pensando em nao usar componentes como o IBTABLE estou querendo fazer toda a manutençao em meu banco atraves de SP´s .. usar IBQuery para fazer consultas ... aproveito a deixa para perguntar aos colegas. Peguei um artigo na net onde o autor diz que se deve usar SP´s para tudo o que se for fazer no banco de dados quando se trabalha com cliente/servidor .. No artigo ele diz que isto diminui consideravelmente os dados trafegados pela rede dando uma maior rapidez na manutenção ... O que vcs acham disto???

A propósito as filias não venderam mercadoria que não seja da fabrica .. ou seja posso manter um unico cadastro de produtos .... O que esta pegando para eu tomar uma decisão é que a fábrica quer ter acesso aos dados das filiais .... por exemplo a fabrica ao final do dia escolhe uma filial e quer ver como foram as vendas ... ou como esta o estoque ... onde determinada referencia esta com estoque baixo para que eles possa fazer reposição de mercadoria ....

Falta pouco para eu decidir o que vou fazer ... se vcs que ja estam me ajudando poderem fazer suas consideraçoes finais quanto ao meu problema ... vai ser de grande ajuda.

o uso de stored procedures ´pra tudo´ é muito abrangente.

geralmente se faz o uso de stored procedures para processos que envolvem várias tarefas.

por exemplo:
você vai baixar uma ordem de produção. o sistema precisa acrescentar o produto ao estoque e dar baixa nessa ordem de produção. então a stored procedure receberia o número dessa OP e, a partir daí teria o código do produto e a quantidade produzida. depois tem que ir à tabela de saldos em estoque, localizar o produto e aumentar a quantidade (essa tarefa pode ser executada numa chamada à outra SP). daí deve efetivar a baixa da OP, colocando uma data de baixa e alterando um status, por exemplo.

outro caso:
efetivar a gravação de uma NF. na stored procedure vc gera os dados financeiros (parcelas para pagamento), faz a manutenção no estoque de cada item (chamaria a mesma SP citada no exemplo anterior), gera as informações fiscais, etc.

alterações simples em tabelas não necessitam de SPs, mas isso requer maior estudo do caso.

o caso da fábrica querer acesso aos dados das filiais é perfeitamente comum.

eu só faria um adendo no caso de a fábrica ver se uma filial ´está com estoque baixo para que eles possam fazer reposição de mercadoria´: isso não é comum.
cada filial tem uma demanda de venda e isso é controlado pela própria filial. imagine que na filial X (devido ao clima da região) saem mais camisas pretas que na filial Y. isso quer dizer que a filial X deveria receber mais camisas pretas que a filial Y. fica complicado pra fábrica ver se a filial ´está com estoque baixo´, não acha?
para resolver esse tipo de problema é colocado um campo ´ponto pedido´ e um campo ´estoque minimo´ numa tabela de [i:e8baefdd6f]dados complementares do produto[/i:e8baefdd6f] (por filial). então, quando o estoque ficar abaixo do valor do campo ´ponto pedido´, o sistema emitiria um pedido daquele produto, com a quantidade igual à diferença entre o ´ponto pedido´ e o estoque atual (somente como sugestão, podendo ser alterado).
no caso da fábrica, quando o estoque do produto atingir o valor do ´ponto pedido´, ao invés do pedido deverá ser emitida uma ordem de produção com uma quantidade (tb sugerida) que mantenha o estoque acima do estoque mínimo.
essa é uma questão que demanda várias páginas, pois você deverá ter, naquela tabela de dados complementares do produto, valores para ´lote mínimo´ e ´lote econômico´, que agirão em conjunto com a ordem de produção, mas esse assunto precisará de mais algumas linhas...