Banco de Dados Em Rede

03/03/2006

0

Amigos,

Atualmente estou com 12 sistemas rodando com 150 usuários (aprox 50 a 60 simultâneos) e todos utilizam bancos de dados em uma rede acessando tabelas em ACCESS!

Até agora, por trabalhar com todos os acessos aos bancos em tempo de execução, não tenho problemas com o número de acessos simultâneos ao access, porém tive que dividir minha base de dados (aprox 90Mb) em várias tabelas para agilizar os acessos. Só que isso dá um tremendo trabalho na hora de gerar códigos... além de ter que ser compactado/reparado com frequência !!

Não temos como colocar um servidor de banco de dados nem uma máquina razoável que sirva de servidor, sendo assim pergunto a opinião dos amigos:

Gostaria de trabalhar com FB ou MySQL, porém acho que ambos precisam de servidores rodando, estou certo ? Alguém tem alguma idéia de como posso resolver esse perrengue ?

A melhor máquina que temos qki é um celereon D com 128Mb de RAM... acho que este não vai aguemtar 60 acessos somultâneos a uma base de 90Mb, mesmo que tudo seja feito via SQL... lembrando que um dos sistemas é tipo um broadcast da bolsa de valores, com atualização a cada minuto!!

Desde já agradeço.


Paulocesar1301

Paulocesar1301

Responder

Posts

03/03/2006

Aroldo Zanela

Colega,

Eu tenho aplicações com Gigas de informações em Firebird, bem como, tenho conhecimento de uma aplicação aqui na região que chega a picos com 500 usuários simultâneos. Mas precisa de máquina.


Responder

03/03/2006

Paulocesar1301

ou seja... estou futricado !!
vou ter que continuar com ACCESS mesmo? :(


Responder

03/03/2006

Paullsoftware

ou seja... estou futricado !! vou ter que continuar com ACCESS mesmo? :(

sinceramente! não continue com access...

procure estudar outro banco de dados, usei access por mais de dois anos e tive muita dor de cabeça, pois, as bases em access quando começam a perder índices fica complicado de resolver quando a base está muito grande tipo (500Mb) eu tive muito trabalho, pensei até em desistir de trabalhar na área, pois, só conhecia de access, mais resolvi estudar SQL e hoje trabalho com Interbase e to estudando Firebird, muito nas minhas aplicaçõs mudaram como: Flexibilidade, Desempenho, Tamanho do DB, problemas minimizaram, elogios dos clientes e mais...

o access é bom?
SIM, mais Interbase principalmente ´FireBird´ eu achei melhor...
o access tem suas vantagens por exemplo para distribuição não conheço outro igual, somente o Exe e o DB, mais vá por mim... falo por experiência própria..!
:wink:


Responder

03/03/2006

Silviogs

Olá amigo

´Atualmente estou com 12 sistemas rodando com 150 usuários (aprox 50 a 60 simultâneos) e todos utilizam bancos de dados em uma rede acessando tabelas em ACCESS!´

1 - se são 150 usuários em uma rede, certo?
2 - e todos utilizam bancos de dados em uma rede, certo?
3 - e acessando tabelas em ACCESS! também em rede, certo?

então pergunto, onde está o servidor?

essa rede é composta por diversos windows? 9x,2000,xp?

então esta rede é workgroup, certo?

ou então algunha máquina está servindo de estação e servidor ao mesmo tempo?

se for, instale o firebird nesta máquina e todas as outras estações acessarão à mesma. (caso esta máquina contenha todos os mdb´s)

uma sugestão utilize componentes de acesso free, como zeoslib 6.5.1 vc com ele faz o acesso direto ao banco de dados sem BDE ou ODBC. Sei que no delphi tem a paleta interbase mas já a utilizei, mesmo assim prefiro o zeos(http://prdownloads.sourceforge.net/zeoslib/zeosdbo-6.5.1-alpha_cvs_13-10-2005.zip?download). Procure melhorar pelo menos uma máquina para que ela possa ser uma estação e servidor ao mesmo tempo já que vc mesmo citou que a melhor máquina é um celerom com 128 mb. Procure argumentar e mostrar a viabilidade que uma rede e principalmente numa empresa precisa de um servidor dedicado para autenticar os usários, gerenciar o banco de dados etc.

obs: agora se vc espalhou os mdb´s por diversas máquinas e todas elas estão servindo de estações e servidores, meu amigo vc está em sérios apuros.

Atenciosamente

Silvio Guedes


Responder

03/03/2006

Paulocesar1301

Caríssimos,
o que temos aqui é um ´HD´ onde os dados (arquivos) são armazenados... um servidor de arquivos comum, os bancos estão todos em uma pesma pasta (para facilitar até mesmo o meu trabalho), porém já tentei e já me informaram que não será possível instalar nenhum servidor/gerenciador de banco de dados no local onde os bancos estão, uma vez que o servidor é utilizado (no geral) por aprox. 2000 usuários.

Por isso estou preocupado... não posso usar nenhum gerenciador que precise ter um server instalado, pois os setores aki são separados e a burocracia é tanta que eles simplesmente barram tudo !!

O access vem trabalhando bem (no esquema Virtual DB), mas acredito que conseguiria melhorar muito a performance se fosse para um gerenciador de BD.

Pergunta idiota : Existe algum gerenciador que não precise de algum server(serviço) rodando ?


Responder

03/03/2006

Silviogs

Carríssimo

entenda bem o seguinte:

se vc que um servidor de banco de dados sem serviço rodando no servidor, então é algo impossível. Já que o access, dbase, piradox e sqlite são meros gerenciadores de arquivos, embrara suportem liguagem sql, não oferecem gerenciamento de transações, stored procedures, trigers, gerenciamento de conexões concorrentes, gerenciamento de segurança com login e grupos e etc.

caso vc insista em usar os gerenciadores acima citados, atente para o seguinte: se alguem com mínimo conhecimento de rede simplesmente acesse o compatilhamento onde estão os mdb´s e resolver apagá-los, vc pegou numha bomba. Estou falando sobre este assunto pq, para os usuários terem acesso aos dados é precisso que a pasta compartilhada seja para escrita e leitura com acesso total, certo?

aqui onde trabalho também temos muita burocracia, por ser um orgão público os setores possuem banco de dados separados, apenas alguns são compartilhados por vários setores e inclusive para todo o estado, mesmo assim temos um servidor intel xeon 3.2 ghz, 2 gb de ram, server 2003 e PostgreSQL 8.1. Até pouco tempo atrás usávamos um pentium 4 com 512 mb de ram e funcionava perfeitamente bem, só na sede do órgão são mais de 100 usuários on-line. Só compramos o novo servidor por precisar disponibilizar o nosso banco de dados na intranet.

Se vc que um serviço de qualidade deve investir.

Atrenciosamente

Silvio Guedes


Responder

03/03/2006

Armando.boza

amigo, seu caso é sério ..

bom, se eu fosse vc procurava um jeito de montar outra maquina para ser o servidor do Firebird, outro detalhe (me corrijam se eu estiver errado).
Para esse número de conexões simultaneas ( 50 - 60 )vc vai precisar de um Linux ou uma versão Server do Windows, pois se não me engano o windows xp aceita até 10 conexões simultaneas.

eu tenho um banco firebird em um hospital aqui na minha cidade com 150.000 atendimentos e mais de 90.000 pacientes cadastrados e a velocidade é surpreendente.


Responder

03/03/2006

Aerreira

(...) porém já tentei e já me informaram que não será possível instalar nenhum servidor/gerenciador de banco de dados no local onde os bancos estão, uma vez que o servidor é utilizado (no geral) por aprox. 2000 usuários.


Se você tem 2000 usuários acessando os dados desse servidor, ele não deve ser tão fraquinho assim (qual o hardware dele? qual sistema operacional?), e não vejo qualquer impedimento em instalar um Firebird nele. Convertendo suas aplicações para firebird e eliminando os atuais acessos aos MDBs neste servidor, certamente a performance melhorará e muito.


Responder

03/03/2006

Gandalf.nho

Sem contar o Firebird é bastante leve e não exige tanto da máquina, ao contrário da grande maioria dos SGDBs.


Responder

03/03/2006

Paulocesar1301

o problema é a burrocracia mesmo, pois o servidor de arquivos é de um determinado setor e estou junto com meus superiores, ter esse simples acesso (FB) e o pessoal de lá breka sempre... não estou vendo saída. !

:( :( :( :( :(


Responder

Assista grátis a nossa aula inaugural

Assitir aula

Saiba por que programar é uma questão de
sobrevivência e como aprender sem riscos

Assistir agora

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar