JOÃO PAULO
não registrado
|
|
ENUNCIADA !
|
|
|
Postada em 28/07/2006 09:06 hs
Pessoal estou usando Access97. Estou ja prevendo que terei problemas logo logo, pois meu banco esta da seguinte forma. TabClientes: 4.000 clientes cadastrados TabPedidos: é cadastrado por dia + ou - 30 pedidos TabVias: é cadastrado 5 registro para cada Pedido. (Tem Relacionamento entre as duas tabelas) ou seja 150 registro por dia na TabVias. A minha pergunta é a seguinte o Access vai aguentar essa demanda de registro? Tem como eu converter meu BD para que ele fique menor?
|
|
|
|
Daniel
|
SÃO PAULO SP - BRASIL
|
|
ENUNCIADA !
|
|
|
Postada em 28/07/2006 09:13 hs
TRabalho com Base Access97 + VB6.0, no meu sistema tem +-7.000 clientes 100 pedidos dia, média de 15 itens por pedido, as bases estão com 3 anos de informação, continuam rápidas e sem comprometimento, 25 terminais acessam a base ao mesmo tempo, jamais tive a base corrompida. Tudo isso é possível SE voce dividir a sua base ou MDBS em várias, exemplo 1 MDB p/Cliente, outra p/Pedido, outra p/Transportadora e assim sucessivamente, trabalho com 15 MDBS diferentes detro do sistema.
dsmn
|
|
|
|
Postada em 28/07/2006 09:23 hs
no menu Ferramentas|utilitário de banco de dados| compactar e reparar banco de dados. por código: Bom, o access começa a perder performance com uns 30.000 registros numa tabela... Agüenta até 2.0 GB de tamanho. Já tive 500.000 registros numa tabela do access e a performance fica aceitável indexando a tabela e fazendo uma pesquisa exata ou pelo início do campo. quero dizer que isto: Select campo from tabela where nome = 'Joao' é mais rápido q isto: Select campo from tabela where nome like 'J%' que é mais rápido q isto: Select campo from tabela where nome like '%J%' Procure usar, se possível, operador lógico AND do q OR. Qto menor for sua área de pesquisa mais rápido terá a resposta. No meu caso tive q dar um jeito no código e me contentar com uma tabela de 500.000 registros no access. Mas se chegar ao pto de inchar já pense em mudar de BD para um MSDE ou até um SQL Server ou Oracle se for o caso. t+
|
|
|
JOÃO PAULO
não registrado
|
|
ENUNCIADA !
|
|
|
Postada em 28/07/2006 09:31 hs
Pessoal muit o brigado pelas dicas.
|
|
|
|
Postada em 28/07/2006 13:14 hs
João Paulo, O Access aguenta até 2 GB de tamanho, e se as select's foram bem estruturadas vc não terá problemas com ele, mesmo pq vc pode criar uma rotina que apaga os dados de antigos de tempo em tempo e compacte o banco. Agora se o seu cliente precisar de um historico grande de informações mude para uma base SQL SERVER.
|
|
|
Sandro
não registrado
|
|
ENUNCIADA !
|
|
|
Postada em 28/07/2006 20:37 hs
João, Eu tenho um sistema feito em VB6 com Access 2000 que está rodando há 5 anos e nunca tive problemas. Na verdade acabei de ter um ontem, mas nada catastrófico, pois consegui reparar a base de dados e não perdi qualquer informação. O meu sistema possui 5 executáveis e eu uso 4 bancos interligados através de tabelas vinculadas. Atualmente essa base de dados está com mais de 160 MB de só a tabela de materiais está com cerca de 9.000 registros. Essa tabela possui ainda outras 4 tabelas relacionadas a ela, cada uma com uma média de 3 registros "filhos" de cada registro da tabela Materiais. Ou seja, tenho cerca de 27.000 registros apenas se referindo a materiais, fora todo o restante do sistema qeue também manipula grandes quantidades de registros. Em cinco anos com um acesso de 35 máquinas simultaneamente e uma quantidade tão grande de registros eu considero um sucesso. Ou seja, o Access pode ser tão confiável quanto outros bancos de dados, embora não tenha a mesma capacidade de restauração que um Oracle ou SQL Server. Entretanto, se o seu banco for bem estruturado, seguindo as regras de normalização para bancos relacionais, não vejo problemas no crescimento do seu banco. A única recomendação que eu faria seria a migração para o Access 2000 que oferece mais segurança que o Access 97. Embora funcione, eu acho que o amigo Daniel exagerou na divisão do banco de 15 partes, eu não faria isso, mas não deixa de ser uma alternativa. Uma boa idéia, no caso de você ter tabelas temporárias no seu banco é o uso de um banco apenas para essas tabelas. um abraço, Sandro.
|
|
|
|