Ouço muita gente falar que o Access é para pequenas aplicações devido a sua limitação de tamanho por banco de dados que é de 2 GBytes, mas a limitação se torna inexistente quando se faz um estudo aprofundado do sistema que se quer construir.
Recentemente tivemos um grande desafio em um cliente. Este tem 17 lojas de materiais de construção, necessitava de um sistema para levantamento de créditos de ICMS, mas onde esta o problema?
Bom, teríamos que fazer um sistema em Access para recuperar os créditos de ICMS a partir do ano de 2005.
Durante o levantamento descobrimos o seguinte:
Cada loja por ano gera em média 2,6 milhões de registros por 93 colunas, gerando pouco mais de 2,3 GB de informações.
Cálculo simples 17 lojas x 4 anos x 2,3 GB por ano = 156,4 GB.
Para efeito de comparação os resultados devem ser calculados com tributos de dois períodos diferentes.
As informações estão em banco Oracle e a empresa não quer que o Oracle seja responsável pelos cálculos, pois iria onerar em muito o banco de dados e as lojas iriam ficar com o sistema lento.
Ainda mais, o usuário deveria ter a possibilidade de executar testes de cálculos como se estivesse no Excel, mas com uma interface gráfica, onde apenas com um clique selecionando os campos desejados, seriam apresentados os cálculos. Também deveria ter a opção de fazer fórmulas avançadas como o Excel (Funções como, por exemplo: SE(), SomaSE(), ProcV() entre outras centenas de formulas).
A solução dada para o cliente foi a seguinte:
O Oracle gera os arquivos textos consolidando as informações das duas tabelas de tributos e o Access efetua a importação distribuindo os dados entre as tabelas, separando-as em uma árvore de pastas da seguinte forma: Filial e Ano.
Na pasta "Ano" serão criadas automaticamente 24 tabelas representando 12 meses com informações geradas com os tributos do primeiro período e mais 12 tabelas com informações geradas com os tributos do segundo período. Assim, não sobrecarregamos o Access com cálculos para exibir resultados dos períodos diferentes, no entanto os 156,4 GB se tornam 312,8 GB divididos em 1.632 arquivos.
Para gerenciar os dados, utilizamos vinculação dinâmica em tempo de execução para que o usuário nem perceba que esta utilizando milhares de bases de dados. Por exemplo, o usuário seleciona a filial 1 e o ano de 2007, automaticamente o sistema vincula as tabelas da referida loja e ano, e poderá usá-las para efetuar seus cálculos "o tempo para vincular as tabelas é em media de 5 segundos.
Mais uma vez vamos aos números:
17 lojas
4 anos por loja
12 meses utilizando valores de tributos período 1
12 meses utilizando valores de tributos período 2
196 MB de informações por mês/loja
Resultado final:
17 * 4 * 24 = 1.632 Arquivos
1632 * 196 MB = 319.872 MB (312,375 GB )
Ainda há quem diz que o Access e um Bando de dados.
Em breve estarei disponibilizando este banco de dados em nosso site.
Pergunta
Patricia Nascimento
Bom dia a todos,
Ouço muita gente falar que o Access é para pequenas aplicações devido a sua limitação de tamanho por banco de dados que é de 2 GBytes, mas a limitação se torna inexistente quando se faz um estudo aprofundado do sistema que se quer construir.
Recentemente tivemos um grande desafio em um cliente. Este tem 17 lojas de materiais de construção, necessitava de um sistema para levantamento de créditos de ICMS, mas onde esta o problema?
Bom, teríamos que fazer um sistema em Access para recuperar os créditos de ICMS a partir do ano de 2005.
Durante o levantamento descobrimos o seguinte:
Cada loja por ano gera em média 2,6 milhões de registros por 93 colunas, gerando pouco mais de 2,3 GB de informações.
Cálculo simples 17 lojas x 4 anos x 2,3 GB por ano = 156,4 GB.
Para efeito de comparação os resultados devem ser calculados com tributos de dois períodos diferentes.
As informações estão em banco Oracle e a empresa não quer que o Oracle seja responsável pelos cálculos, pois iria onerar em muito o banco de dados e as lojas iriam ficar com o sistema lento.
Ainda mais, o usuário deveria ter a possibilidade de executar testes de cálculos como se estivesse no Excel, mas com uma interface gráfica, onde apenas com um clique selecionando os campos desejados, seriam apresentados os cálculos. Também deveria ter a opção de fazer fórmulas avançadas como o Excel (Funções como, por exemplo: SE(), SomaSE(), ProcV() entre outras centenas de formulas).
A solução dada para o cliente foi a seguinte:
O Oracle gera os arquivos textos consolidando as informações das duas tabelas de tributos e o Access efetua a importação distribuindo os dados entre as tabelas, separando-as em uma árvore de pastas da seguinte forma: Filial e Ano.
Na pasta "Ano" serão criadas automaticamente 24 tabelas representando 12 meses com informações geradas com os tributos do primeiro período e mais 12 tabelas com informações geradas com os tributos do segundo período. Assim, não sobrecarregamos o Access com cálculos para exibir resultados dos períodos diferentes, no entanto os 156,4 GB se tornam 312,8 GB divididos em 1.632 arquivos.
Para gerenciar os dados, utilizamos vinculação dinâmica em tempo de execução para que o usuário nem perceba que esta utilizando milhares de bases de dados. Por exemplo, o usuário seleciona a filial 1 e o ano de 2007, automaticamente o sistema vincula as tabelas da referida loja e ano, e poderá usá-las para efetuar seus cálculos "o tempo para vincular as tabelas é em media de 5 segundos.
Mais uma vez vamos aos números:
17 lojas
4 anos por loja
12 meses utilizando valores de tributos período 1
12 meses utilizando valores de tributos período 2
196 MB de informações por mês/loja
Resultado final:
17 * 4 * 24 = 1.632 Arquivos
1632 * 196 MB = 319.872 MB (312,375 GB )
Ainda há quem diz que o Access e um Bando de dados.
Em breve estarei disponibilizando este banco de dados em nosso site.
att,
Editado por Patricia NascimentoLink para o comentário
Compartilhar em outros sites
3 respostass a esta questão
Posts Recomendados
Participe da discussão
Você pode postar agora e se registrar depois. Se você já tem uma conta, acesse agora para postar com sua conta.