Access VS. Paradox

Question

Estou p/ iniciar o desenolvimento de um m�dio sistema, e gostaria q os mais experientes do forum me dessem uma dica: qual melhor sistema p/ criar minhas tabelas, no ACCESS ou em PARADOX, detalhe s�o os �nicos que at� hoje fiz alguma coisa. Grato desde j� por aqueles que opinarem.

Vinicius2k · Answer

Colega,O Access � mais robusto e seguro que o Paradox. Se puder evit�-los, n�o utilize BDE e/ou ODBC... Recomendo a utiliza��o o banco Access e a tecnologia ADO + OleDB Provider (Jet 4) para acesso.Se tiver tempo e disponibilidade para aprendizado, sugiro que estude sobre SGBDs como o Firebird e MS-SQL Server (MSDE), que s�o excelentes op��es sem custo agregado. Se estiver �enforcado� com o tempo, adote o Access (ao menos por enquanto), mas tenha em mente que o volume de dados, compromete a performance da aplica��o em uma escala muito maior do que com um SGBD.Boa sorte !T+...

Flacandido · Answer

Caro colega, obrigado por compartilhar de sua opini�o, vejo que possui um consideravel conhecimento do assunto, por isso tenho mais uma d�vida, qual o limite aceit�vel de registros que uma tabela em ACCESS pode conter??? Espero q possa me ajuda.

Vinicius2k · Answer

Colega,N�o conhe�o um �limite�, se ele existir... J� vi tabelas em bancos Access com mais de um milh�o de registros e diversos bancos que, no total, possuiam mais de 500 MB.Este tamanho pode ser considerado pequeno para os SGBDs, mas com certeza, � bem grande para bancos desktop como o Access. O seu maior problema utilizando Access n�o ser� os limites do banco, propriamente dito, e sim tr�fego na rede. Como os bancos desktop transportam todos os registros pela rede e o tratamento � feito inteiramente pela esta��o, o trafego � bastante grande e o desempenho da aplica��o estar� intimamente ligado � largura da banda e eficiencia da sua rede, bem como com a capacidade de processamento das esta��es.Por este motivo, n�o � recomendado (mas nada o impede) que vc tenha mais de 10 esta��es operando a mesma aplica��o de forma concorrente.Vc precisa � de uma boa rede, servidor e esta��es com discos r�pidos e muita mem�ria. Se tiver isso, deve demorar um pouco at� sentir o �peso� do Access, mas ir� sent�-lo antes do que se estivesse utilizando um SGBD.T+...

Flacandido · Answer

Caro colega Vinicius2K, primeiramente gostaria de agradecer pelo seus esclarecimentos, sobre o ACCESS, o que vc acha de criar mais de um banco de dados, no qual guardaria tabelas que tendem a crescer numa propor��o maior q as demais, como o caso de Vendas, Compras, Movimento de Caixa. Deste modo ap�s um per�odo de uso (1 ano por exemplo) exportaria p/ um novo banco estes registros apenas c/ a fun��o de manter um hist�rio, apagando posteriormente do banco de dados atual os mesmos registros e permitindo ao usu�rio a qualquer momento consult�-los, resulmindo, de periodo em periodo criaria um novo banco e nele guardaria determindas tabelas e respectivos registros, mantendo sempre a principal c/ uma qtde de registros aceit�veis.

Raserafim · Answer

vinicius, vc tocou em um ponto que me fez pensar mas sem ter a resposta:

Como os bancos desktop transportam todos os registros pela rede e o tratamento � feito inteiramente pela esta��o, o trafego � bastante grande

se eu tiver uma base em Access e acessa-la atrav�s de uma rede utilizando comandos SQL, mesmo assim v�o ser trazido todos os registros para serem tratados na m�quina cliente? ou vir�o apenas os registros j� filtrados pela instru��o SQL?

Aroldo Zanela · Answer

[quote:27cf7daa17=�raserafim�]vinicius, vc tocou em um ponto que me fez pensar mas sem ter a resposta:[quote:27cf7daa17]Como os bancos desktop transportam todos os registros pela rede e o tratamento � feito inteiramente pela esta��o, o trafego � bastante grande[/quote:27cf7daa17]se eu tiver uma base em Access e acessa-la atrav�s de uma rede utilizando comandos SQL, mesmo assim v�o ser trazido todos os registros para serem tratados na m�quina cliente? ou vir�o apenas os registros j� filtrados pela instru��o SQL?[/quote:27cf7daa17]Colega,Qualquer banco de dados que n�o seja SGBD (Client/Server) opera por compartilhamento de arquivo e o subset do SQL ANSI 92 suportado pelas engines fazem a tarefa na esta��o. Portanto, o tr�fego na rede � intenso.O Limite do Access � (ou era) de 2 GB, por�m, a pr�pria Microsoft n�o recomenda o uso de mais de 50� deste valor, ou seja, mantenha-o at� 1 GB para evitar problemas. Tenho relatos de mal comportamento dele com volumes muitos grandes de dados (pr�ximo a 1 GB) em rede, por�m, o mesmo sistema operou normalmente de forma stand-alone.Acredito que sua id�ia de particionar o banco � ideal para suportar este volume que voc� espera. Eu recomendo voc� planejar um upsize de banco (Firebird)o quanto antes, visando n�o ter maiores transtornos com a aplica��o....

Silviogs · Answer

Ol� amigoos relatos citados acima s�o de profundos conhecimentos t�nicos de nossos amigos aqui do forum, mas aconselho usar um Banco de Dados(Interbase, Firebird, Postgre etc.) al�m de serem free vc pode usar o acesso direto com o ZeosLib(free), exemplo j� postado no forum. Com Delphi 7 e 2005 funciona sem problemas.veja este t�pico://forum.devmedia.com.br/viewtopic.php?t=58753&highlight=paradox&sid=7c0b9674e98d151280014052d9875244 AtenciosamenteSilvio Guedes...

Vinicius2k · Answer

Colega flacandido,Apenas em complemento ao que j� foi colocado pelo Aroldo, tamb�m penso que a id�ia de particionar o banco � a melhor forma de reduzir as possibilidades de problemas utilizando o Access.Como disse desde o primeiro post, o ideal � que vc utilizasse um SGBD, mas se n�o for poss�vel por enquanto, j� estude e planeje uma futura migra��o.T+...

Edilcimar · Answer

sinceramente, se tiver que escolher APENAS entre Access e Piradox escolha  o Firebird...

Nerdex · Answer

Mais leve... mais �gil... incompar�vel...[url]//forum.devmedia.com.br/viewtopic.php?t=61175&sid=5fb936ff680336ddceb1a09074389c94[/url]...

Nerdex · Answer

Solu��o monousu�rio de qualidade:[url]//www.clubedelphi.net/artigos/SQLite.asp[/url][img:f429969f51]//www.sqlite.org/sqlite.gif[/img:f429969f51]...

F�rum Access VS. Paradox #275308