ORGANIZAR BANCO DE DADOS
Bom dia pessoal ...... 
Vou começar a fazer um programa completo de contabilidade, controle finaceiro, cadastros, etc ... e vou utilizar bco de dados access e via DAO (só sei trabalhar com esse - nao manjo de ADO, firebird etc - NEM ME FALEM DE MIGRAÇÃO PORQUE SE EU MIGRAR DE BANCO DE DADOS TEREI ME MIGRAR PARA O VB.NET TAMBEM ....
)
MAS é O SEGUINTE:
nos modulos contabilidade finança, etc ... vai ser usado varias tabelas.
Pergunto eu ..... PRA CADA FORMULARIO DE OPERAÇÃO POSSO CRIAR UM MDB???? OU é MELHOR JOGAR TUDO EM UM MESMO ARQUIVO???
SE EU UTILIZAR UM MESMO ARQUIVO, SE DER PROBLEMAS NAO IREI PERDER TUDO?????
COMO FAÇO PRA ORGANIZAR ................ NAO TENHO MUITA EXPERIENCIA NISSOO
OBRIGADO ...... A QUEM CONTRIBUIR
Vou começar a fazer um programa completo de contabilidade, controle finaceiro, cadastros, etc ... e vou utilizar bco de dados access e via DAO (só sei trabalhar com esse - nao manjo de ADO, firebird etc - NEM ME FALEM DE MIGRAÇÃO PORQUE SE EU MIGRAR DE BANCO DE DADOS TEREI ME MIGRAR PARA O VB.NET TAMBEM ....
)MAS é O SEGUINTE:
nos modulos contabilidade finança, etc ... vai ser usado varias tabelas.
Pergunto eu ..... PRA CADA FORMULARIO DE OPERAÇÃO POSSO CRIAR UM MDB???? OU é MELHOR JOGAR TUDO EM UM MESMO ARQUIVO???
SE EU UTILIZAR UM MESMO ARQUIVO, SE DER PROBLEMAS NAO IREI PERDER TUDO?????
COMO FAÇO PRA ORGANIZAR ................ NAO TENHO MUITA EXPERIENCIA NISSOO
OBRIGADO ...... A QUEM CONTRIBUIR
Cara, só vai perder tudo que não vai fazer backup! e como eu já li aqui uma vez: [txt-color=#FF0000]quem tem um backup tem nenhum![/txt-color]
Agora quanto a divisão do banco de dados, eu acho super importante realmente vc fazer isso, pois o Access tem as suas limitações com o todos sabem. O lance é vc saber a projeção que o teu sistema terá em decidir quantos mdbs criará e quais tabelas existirão neles. No clássico modelo básico de um sistema de vendas. Temos as tabelas dos pedidos, dos tÃtulos, dos Produtos, dos Clientes. Sabemos que essas quatros tem um aumento siginificativo com o tempo, portanto são candidatas a estarem num mdb particular. O relacionamento com outras tabelas pode ser obtido por vinculação de tabelas entre mdbs. Uma boa dica é c saber usar objetos workspaces da DAO pra gerenciar transações com múltiplos banco de dados.
As suas escolhas tem que se basear num levantamento minucioso. Não deixe o cliente afoito, que sempre quer tudo pra ontem, te induzir a fazer algo ruim.
Agora quanto a divisão do banco de dados, eu acho super importante realmente vc fazer isso, pois o Access tem as suas limitações com o todos sabem. O lance é vc saber a projeção que o teu sistema terá em decidir quantos mdbs criará e quais tabelas existirão neles. No clássico modelo básico de um sistema de vendas. Temos as tabelas dos pedidos, dos tÃtulos, dos Produtos, dos Clientes. Sabemos que essas quatros tem um aumento siginificativo com o tempo, portanto são candidatas a estarem num mdb particular. O relacionamento com outras tabelas pode ser obtido por vinculação de tabelas entre mdbs. Uma boa dica é c saber usar objetos workspaces da DAO pra gerenciar transações com múltiplos banco de dados.
As suas escolhas tem que se basear num levantamento minucioso. Não deixe o cliente afoito, que sempre quer tudo pra ontem, te induzir a fazer algo ruim.
Vou deixar minha opinião quanto à dúvida.
Um programa com esta dimensão (pois pelas declarações que fez, cheguei a esta conclusão), deveria usar como base de dados um SGBD.
ACCESS, seja em VB6, VB.NET ou C#, só utilizo para aplicações DESKTOP MUIIIIIIIITO SIMPLES.
Outra coisa, para se mudar de BANCO DE DADOS, não é necessário MIGRAR PARA .NET. São duas coisas totalmente distintas. Trabalho com .NET há 7 meses, mas ainda tenho várias aplicações rodando em VB6 com FIREBIRD, SQL SERVER 2005 EE e MySQL.
Voltando ao tópico, sugiro que utilize somente UM BANCO DE DADOS, com as TABELAS vinculadas com PK e FK, desde que o mesmo seja um SGBD.
PS. Evite um problema futuro, mude a base de dados.
Um programa com esta dimensão (pois pelas declarações que fez, cheguei a esta conclusão), deveria usar como base de dados um SGBD.
ACCESS, seja em VB6, VB.NET ou C#, só utilizo para aplicações DESKTOP MUIIIIIIIITO SIMPLES.
Outra coisa, para se mudar de BANCO DE DADOS, não é necessário MIGRAR PARA .NET. São duas coisas totalmente distintas. Trabalho com .NET há 7 meses, mas ainda tenho várias aplicações rodando em VB6 com FIREBIRD, SQL SERVER 2005 EE e MySQL.
Voltando ao tópico, sugiro que utilize somente UM BANCO DE DADOS, com as TABELAS vinculadas com PK e FK, desde que o mesmo seja um SGBD.
PS. Evite um problema futuro, mude a base de dados.
Citação:TECLA DISSE: Voltando ao tópico, sugiro que utilize somente UM BANCO DE DADOS, com as TABELAS vinculadas com PK e FK, desde que o mesmo seja um SGBD.
Nao tenho um conhecimento muito profundo na área de software ......... mas na parte tecnica sim porque sou tecnico em contabilidade e tenho outros cursos relativo à area ........ agora com relação ao SGBD eu fiz uma pesquisa no google e vi que esse SGDB em haver com SQL, inclusive tem isso haver com MYSQL ou outras do genero???? como disse só conheço ACCESS e DAO ..... ????
é cara, se vc não tem interesse em aprender novas tecnologias devido vc ser e outra área ou falta de tempo, a opção com DAO e Access é boa desde que vc modele muito bem os bancos, e não pendure terminais nele.
Boa sorte!
Boa sorte!
Leandro .......... o que vc quis dizer com ..
Citação:modele muito bem os bancos, e não pendure terminais nele
Minha experiência:
Ha uns 2 anos atrás fiz um programinha parecido com o que vc vai fazer: ACCESS + DAO. Hoje sofro com usuários reclamando de lentidão, já tive problemas com desligamento do serrvidor e perda de dados...
Este programa foi o último com ACCESS + DAO. Agora só utilizo MySQL + ADO. E só vi vantagens.
Na pática, pouca coisa muda do DAO + ACCESS para ADO + MySQL, vc não vai ter que reaprender nada do zero.
Hoje nem me lembro mais como se mexe com DAO... O MySQL é muito muito simples. Tão fácil quanto ACCESS. Só o instalei e começei a criar tabelas e relacionamentos. Acho mais limpo e fácil de aprender para quem está saindo do ACCESS do que o SQL SERVER Express.
ACCESS vai servir durante um certo tempo, dependendo de como vc faz suas consultas, provavelmente não muito tempo depois vc irá sentir os efeitos negativos...
[ ]'s
Ha uns 2 anos atrás fiz um programinha parecido com o que vc vai fazer: ACCESS + DAO. Hoje sofro com usuários reclamando de lentidão, já tive problemas com desligamento do serrvidor e perda de dados...
Este programa foi o último com ACCESS + DAO. Agora só utilizo MySQL + ADO. E só vi vantagens.
Na pática, pouca coisa muda do DAO + ACCESS para ADO + MySQL, vc não vai ter que reaprender nada do zero.
Hoje nem me lembro mais como se mexe com DAO... O MySQL é muito muito simples. Tão fácil quanto ACCESS. Só o instalei e começei a criar tabelas e relacionamentos. Acho mais limpo e fácil de aprender para quem está saindo do ACCESS do que o SQL SERVER Express.
ACCESS vai servir durante um certo tempo, dependendo de como vc faz suas consultas, provavelmente não muito tempo depois vc irá sentir os efeitos negativos...
[ ]'s
Não vou nem discutir migração, pois os colegasacima já deixaram bem claro como é facil e seguro migrar de DAO para ADO, e access para MYSQL FIREBIRD, etc.
Você deve fazer tudo me um unico banco de dados e manter Backups atualizados por dias ou periodos
Você deve fazer tudo me um unico banco de dados e manter Backups atualizados por dias ou periodos
O que eu posso lhe sugerir é buscar aprender um pouco mais sobre banco de dados, em especial SGDB.
Pela caracterÃstica do seu projeto, vc realmente precisará de um banco de dados bem mais robusto que o access, para poder utilizar recursos que lhe dêem ganho de velocidade de processamento e funcionalidades que o access não tem: triggers, procedures, maior segurança de acesso e backup.
Utilizo atualmente firebird e consigo ter resultados excelentes. Fácil de instalar, distribuir e operar.
Pela caracterÃstica do seu projeto, vc realmente precisará de um banco de dados bem mais robusto que o access, para poder utilizar recursos que lhe dêem ganho de velocidade de processamento e funcionalidades que o access não tem: triggers, procedures, maior segurança de acesso e backup.
Utilizo atualmente firebird e consigo ter resultados excelentes. Fácil de instalar, distribuir e operar.
Putsss ........................ naum tem jeitoooooo ...........................
onde é q eu consigo apostilas e codigos fontes pra estudar isso ................ ??????
o pessoal ta batendo duro a cerca de vb.net !!!! bommmm ate uns bons tempos atras eu utilizava qbasic 4.5 .... agora vb6 ..... foi uma mudança tremenda ........ levei uns 2 anos pra aprender tudo .......... so fico pasmado q se eu migrar, depois de pegar o [Ô]jeito[Ô] vai ter coisas mais sofisticadas ..... eaiiii o q aprendi vai ficar absoletooo
TENHO MUITO O Q A APRENDER ........... SEI DISSO ........... MAS O PROBLEMA E TEMPO, E RETORNO ( $$$) DO QUE APRENDI !!!
onde é q eu consigo apostilas e codigos fontes pra estudar isso ................ ??????
o pessoal ta batendo duro a cerca de vb.net !!!! bommmm ate uns bons tempos atras eu utilizava qbasic 4.5 .... agora vb6 ..... foi uma mudança tremenda ........ levei uns 2 anos pra aprender tudo .......... so fico pasmado q se eu migrar, depois de pegar o [Ô]jeito[Ô] vai ter coisas mais sofisticadas ..... eaiiii o q aprendi vai ficar absoletooo
TENHO MUITO O Q A APRENDER ........... SEI DISSO ........... MAS O PROBLEMA E TEMPO, E RETORNO ( $$$) DO QUE APRENDI !!!
Tópico encerrado , respostas não são mais permitidas