Atenção: por essa edição ser muito antiga não há arquivo PDF para download. Os artigos dessa edição estão disponíveis somente através do formato HTML.
Access X Paradox
Qual é o melhor e mais confiável arquivo de dados?
Quem trabalha com banco de dados,sabe que as primeiras e principais, preocupações no desenvolvimento de um projeto são segurança e velocidade. Em determinados sistemas, este assunto é levado tão a sério que boa parte do tempo total de análise e de desenvolvimento é gasto pensando neste aspecto. Sempre que possível, estarei aqui dando dicas e tentando economizar seu tempo na hora de levantar dados para implementação de seu sistema. Como você já ter percebido no título, o assunto em questão é uma comparação feita entre talvez os dois banco de dados não cliente-servidores mais utilizados com o Delphi: o PARADOX e o MS ACCESS. Foram testes de complexidade simples, na qual medimos o desempenho e segurança de ambos ao serem utilizados através do Delphi (com BDE). Em breve testaremos o acesso a banco de dados sem BDE (via ADO) e publicaremos uma matéria sobre o assunto.
O primeiro passo realizado foi definir a estrutura das tabelas e preenchê-las com registros. A estrutura criada foi um campo numérico, para servir de chave primária, quatro campos string, de tamanho 50, e quatro campos numéricos. Após criarmos as tabelas no Paradox e no Access, o objetivo passou a ser o preenchimento das tabelas com uma quantidade razoável de registros. A segurança começou a ser analisado a partir daí. A quantidade de registros que chegamos foi 470.000, concluídos a partir de uma rotina geradora de valores aleatórios. Durante a inclusão, demos boot no computador algumas vezes, para ver como elas se comportariam. Com paradox, o resultado foi previsível: apresentou vários problemas de corrupção de índices. Já com o ACCESS, a história não foi a mesma: ao voltar do boot, simplesmente o arquivo não era mais reconhecido como um arquivo ACESS. Refizemos todo o processo e o problema repetiu, até que decidimos realizar a inclusão na tabela dentro do próprio ACCESS. Só então ele funcionou.
Outra questão foi sobre compôs auto-incrementáveis: no Paradox, o campo chave foi criado como autoincrement e várias vezes durante os testes, o campo se perdia, oferecendo o mesmo valor, e gerando o erro “key violation”. Só conseguimos trabalhar corretamente depois de mudar a chave primária para long interger, e incrementar via código.
Com as tabelas preenchidas, vieram os problemas: no paradox, foram inúmeros. Várias corrupções de índice, inclusive um caso curiosos, e de muito perigo: em certo momento, a tabela perdeu a sua ordenação pelo campo código, apesar de este ser o campo chave. Ao tentarmos reindexá-lo, o database desktop simplesmente exibia a mensagem: “table is full.”Então,deletemos o arquivo de índice e o contruímos novamente.Desta vez, ganhamos a mensagem:’’Index File or Header is Corrupt’’. Após isto a tabela ficou inutilizada, obrigando-nos a perder todos os dados e executar toda a operação novamente.O ACCESS não apresentou problemas.
A conclusão dos testea foi razoável: na média, o arquivo PARADOX mostrou maior robustez.
Estes testes foram meramente ilustrativos, e com eles, não quero desestimular o uso do Pradox, mas dar apenas uma idéia para quem está definindo qual tipo de tabela iráusar em seus sistemas,já que as lendas e boatos são enormes em torno deste assunto.Gostaria de enfatizar que se você tiver a possibilidade de usar um banco de dados cliente-servidos, está será, sem dúvida a melhor escolha.
Os testes foram realizados em um Pentium em 133, 32mb RAM, HD 2.5 gb(1.6 gb livres), com Delphi 4, Access 97 e paradox 7. Abaixo segue uma tabela resumida da média alcançada em alguns dos testes. Críticas e susgestões sobre está matéria podem ser enviadas para admin@clubedelphi.com.br
|
Teste |
Paradox |
Access |
|
Tamanho do arquivo (470.000 registros) |
103 mb |
108 mb |
|
Abrir objeto Table (Table1.open) |
2 segs |
5 segs |
|
Pesquisa na chave (Table1.Findkey) |
(-)1 seg |
(-1) Seg |
|
Filtro na chave primária, selecionando 100.000 registros |
9 segs |
1:18 min |
|
Ir para o último registro do filtro acima |
2:46 min |
5:51 min |
|
Abrir Query, selecionando todos os registros |
3 segs |
1 Seg |
|
Filtrar 100.000 registros usando Query(chave primária) |
13 segs |
2 segs |
|
Ir para o último registro com a Query acima |
9 segs |
29 segs |
|
Selecionar o registro chave 250.000 |
3 segs |
7 segs |
|
Filtrar por string (operador Like com '%' no final) |
1:17 min |
35 segs |
|
Filtrar por string (operador Like com '%' no início e fim) |
1:25 |
52 segs |
