Desenvolvimento em Access

Max Willian Ourique · 1 de julho de 2005

Olá...

Gostaria de ouvir a opinião de quem tem experiência com desenvolvimeto de sistemas de pequeno porte. Acho simples e prático desenvolver bancos de dados em access, no entanto, como não tenho muita experiência, tenho receio quanto a consistência e confiabilidade em soluções by access.

Por exemplo, se eu criar um banco de dados de informações de clientes de uma empresa. Funciona, eu sei, mas ao longo do tempo quando houver bastante informação, continuará redondo o sistema? E mais, se eles quiserem acessar os dados em rede, não vai dá crep?

Sei que a melhor coisa seria um programa desenvolvido para atuar junto com um banco mais confiável. Mas eu ainda não saí das caixa. E no access eu até que me viro.

O que você pode me dizer?

wells · 1 de julho de 2005

eae beleza??

Bom cara... o bom mesmo seria fazer isso, um sistema acessando o BD...

MAS pra comecar voce pode fazer apenas pelo ACCESS mesmo. Mas com planejamento para fazer um sistema direitinho.

Agora, vê se faz uma modelagem maneira nesse BD... tipo relacionamentos, normalizações etc... porque aí fica mais difícil de dar algum problema.

E a medida que voce for aprendendo alguma linguagem voce comeca a desenvolver o sistema.

valeu!

Wells

Clemente Silva · 4 de julho de 2005

Postado Originalmente por Max Willian Ourique@01 de julho de 2005, 13:12
Gostaria de ouvir a opinião de quem tem experiência com desenvolvimeto de sistemas de pequeno porte. Acho simples e prático desenvolver bancos de dados em access, no entanto, como não tenho muita experiência, tenho receio quanto a consistência e confiabilidade em soluções by access.

Por exemplo, se eu criar um banco de dados de informações de clientes de uma empresa. Funciona, eu sei, mas ao longo do tempo quando houver bastante informação, continuará redondo o sistema? E mais, se eles quiserem acessar os dados em rede, não vai dá crep?

Sei que a melhor coisa seria um programa desenvolvido para atuar junto com um banco mais confiável. Mas eu ainda não saí das caixa. E no access eu até que me viro.

Aí tem dois casos a analisar: o uso do Microsoft Access:

1) como "aplicação"

2) como "banco de dados"

Usar o Access como aplicação, não dá (na minha opinião). É impossível desenvolver uma solução decente com os recursos limitados do VBA e da interface gráfica.

Porém, apenas como base de dados até que é viável, mas aí vai depender do tamanho e da estrutura da empresa onde você pretende implementar.

O Access pode trabalhar maravilhosamente bem, hospedado num potente servidor com s.o. de rede bem configurado, com 10 excelentes máquinas conectadas por uma rede montada por profissionais (cabeamento passando pelo conduíte ou então por canaletas, sem aquele monte cabos espalhados pelo chão, com todo mundo pisando em cima, etc)...

Porém pode ser desastroso no "bazar da esquina" com dois 486 rodando Windows 95 numa rede antiga e cheia de gambiarras. O problema é que o "dono do bazar da esquina" jamais vai querer entender isso, então aí é outra história (esse é o tipo de cliente que hoje, felizmente, eu posso dispensar com a maior alegria).

E outra: sempre (SEMPRE) implemente rotinas de manutenção e backup periódicas e, de preferência, automáticas. Isso porque (sem querer generalizar, mas generalizando) nenhum administrador de sistema costuma fazer sequer um backup semanal, o que é um absurdo (para mim, o ideal é fazer backup todos os dias).

Eu, por exemplo, uso o Access apenas como banco de dados, e o VB para desenvolver a aplicação. Já tive alguns problemas com banco de dados Access, mas poderiam ter sido evitados caso o responsável pela administração do sistema tivesse usado as ferramentas de manutenção que eu dispuz.

Para uma das empresas onde implantei sistemas com banco de dados Access, a irresponsabilidade quanto ao backup era tão grande que eu precisei alterar o sistema para obrigar o administrador à efetuar o login todos os dias antes de todos os outros usuários, e fazer o backup. Eu fiz de um modo que, enquanto o administrador não faz o backup do banco de dados, ninguém pode usar o sistema.

Então, o mais importante de tudo é: certifique-se de que a manutenção e o backup serão feitos.

São essas medidas que tornam um banco de dados mais ou menos confiável, pois quando uma empresa perde dias, meses ou anos de trabalho por causa de irresponsabilidade de seu próprio pessoal, não importa se o banco de dados é Access ou Oracle.

[]'s

MikoCWB · 4 de julho de 2005

Usando MDAC para acessar o BD você pode usar o mesmo codigo fonte para tanto ACCESS ou MS SQL server. Assim o seu cliente pode migrar depois.

Clemente Silva · 4 de julho de 2005

Postado Originalmente por MikoCWB@04 de julho de 2005, 11:05
Usando MDAC para acessar o BD você pode usar o mesmo codigo fonte para tanto ACCESS ou MS SQL server. Assim o seu cliente pode migrar depois.

?

MDAC (Microsoft Data Access Components) é o conjunto de todas as bibliotecas de acesso a bancos de dados "padrão Microsoft", portanto não se usa especificamente "o MDAC", mas sim usa-se mais comumente o ADO (ActiveX Data Objects), que está contido no MDAC.

Porém, eu acredito que o colega Max Willian Ourique esteja usando os métodos e objetos nativos do próprio Microsoft Access na sua aplicação, o que significa que ele está usando a antiga biblioteca DAO (Data Access Components) ao invés do ADO.

Nesse caso, é praticamente inviável o aproveitamento do código para acessar um outro banco de dados que não seja o próprio Access.

E depois, não tem sentido usar o Access como "front end", acessando um banco de dados SQL Server. O ideal seria desenvolver essa interface em VB ou Delphi acessando SQL Server (ou outro banco de dados).

[]'s

MikoCWB · 4 de julho de 2005

Falei alguma coisa errado ?

Me desculpe então...

E na minha opiniao "O ideal seria desenvolver essa interface em você# ou você++ acessando Acess ou SQL Server"

Me desculpe - tb sou muito chato....

Clemente Silva · 5 de julho de 2005

Postado Originalmente por MikoCWB+04 de julho de 2005, 17:21-->
Falei alguma coisa errado?
Não totalmente errada, mas faltou apenas ser mais específico, afinal o colega que postou o tópico precisa da sua dúvida esclarecida (e não de novas dúvidas criadas).
Postado Originalmente por MikoCWB@04 de julho de 2005, 17:21
Me desculpe então...

Não há porque se desculpar. Eu é que peço desculpas, caso minha mensagem anterior tenha lhe parecido irônica (garanto que não foi minha intenção).
MikoCWB@04 de julho de 2005, 17:21

E na minha opiniao "O ideal seria desenvolver essa interface em você# ou você++ acessando Acess ou SQL Server"

Eu também acho o ideal, porém:

=> O cliente vai querer é ver "a coisa funcionando". Para o cliente, desde que funcione, pouco importa se você desenvolveu em VB, Delphi, C, etc etc etc...

=> Apesar das ferramentas citadas serem infinitamente superiores as ferramentas RAD existentes, são muito pouco produtivas para este tipo de aplicação relatada neste tópico. Portanto, o VB (principalmente o .Net) ou o Delphi seriam as ferramentas ideais, e não apenas na minha opinião (pode consultar qualquer profissional da área e ele certamente vai lhe dizer o mesmo).

Postado Originalmente por MikoCWB@04 de julho de 2005, 17:21
Me desculpe - tb sou muito chato...

Mais uma vez, não há porque se desculpar, afinal não houve aqui ofensas nem críticas pessoais, mas apenas divergências "leves" de opinião, seguidas de algumas trocas de idéias.

Que assim continue.

Max Willian Ourique · 17 de agosto de 2006

Olá pessoal... estava lendo suas respostas ao meu post.

Agradeço desde já sua colaboração.

:palmas:

Aí tem dois casos a analisar: o uso do Microsoft Access:

1) como "aplicação"

2) como "banco de dados"

Usar o Access como aplicação, não dá (na minha opinião). É impossível desenvolver uma solução decente com os recursos limitados do VBA e da interface gráfica.

Porém, apenas como base de dados até que é viável, mas aí vai depender do tamanho e da estrutura da empresa onde você pretende implementar.

O Access pode trabalhar maravilhosamente bem, hospedado num potente servidor com s.o. de rede bem configurado, com 10 excelentes máquinas conectadas por uma rede montada por profissionais (cabeamento passando pelo conduíte ou então por canaletas, sem aquele monte cabos espalhados pelo chão, com todo mundo pisando em cima, etc)...

Porém pode ser desastroso no "bazar da esquina" com dois 486 rodando Windows 95 numa rede antiga e cheia de gambiarras. O problema é que o "dono do bazar da esquina" jamais vai querer entender isso, então aí é outra história (esse é o tipo de cliente que hoje, felizmente, eu posso dispensar com a maior alegria).

E outra: sempre (SEMPRE) implemente rotinas de manutenção e backup periódicas e, de preferência, automáticas. Isso porque (sem querer generalizar, mas generalizando) nenhum administrador de sistema costuma fazer sequer um backup semanal, o que é um absurdo (para mim, o ideal é fazer backup todos os dias).

Eu, por exemplo, uso o Access apenas como banco de dados, e o VB para desenvolver a aplicação. Já tive alguns problemas com banco de dados Access, mas poderiam ter sido evitados caso o responsável pela administração do sistema tivesse usado as ferramentas de manutenção que eu dispuz.

Para uma das empresas onde implantei sistemas com banco de dados Access, a irresponsabilidade quanto ao backup era tão grande que eu precisei alterar o sistema para obrigar o administrador à efetuar o login todos os dias antes de todos os outros usuários, e fazer o backup. Eu fiz de um modo que, enquanto o administrador não faz o backup do banco de dados, ninguém pode usar o sistema.

Então, o mais importante de tudo é: certifique-se de que a manutenção e o backup serão feitos.

São essas medidas que tornam um banco de dados mais ou menos confiável, pois quando uma empresa perde dias, meses ou anos de trabalho por causa de irresponsabilidade de seu próprio pessoal, não importa se o banco de dados é Access ou Oracle.

[]'s