QUE SISTEMA DEVO USAR PARA GERIR GRANDE QUANTIDADE
Concordo com o AJSO, mesmo programando com ferramentas atuais e de ponta... um sistema pode ficar bem lento por N fatores..
O negocio é saber usar a ferramenta que tens em maos !
O negocio é saber usar a ferramenta que tens em maos !
Realmente, um exemplo bem simples de se utilizar a tecnologia adequada é utilizar um banco com suporte a ADO.NET, e usar ODBC para manipula-ló. Não vai adiantar ter um banco com muita performance e utuliza-ló com uma tecnologia de menor performance. Para se ter um desempenho é utilizar com o que a plataforma tem o de melhor para nos oferecer, e vai por mim camarada, essa plataforma .NET faz muitas coisas incrÃveis. Quando estiveres com um sistema feito em camadas, utilizando os recursos adequadamente, verás a diferença.
Antigamente quando eu desenvolvia em VBA, eu estava fazendo um sistema que utilizava um banco em ACCESS mesmo, e então fiz um teste com os meus dados armazenados em MYSQL. Ao atualizar um único registro tinha uma diferença de 4 segundos, ou seja, cada registro demorava 4 segundos e já no MYSQL não dava nem dois direito. Lembrando que já aparentava essa diferença em VBA, já pensou isso em VB.NET, que sem dúvidas é mais rápido.
Outro teste também que já fiz aqui, foi tentar calcular a quantidade de dados inseridos em um determinado tempo, tinha um Datagridview com 8 colunas, e 1000 linhas, eu conseguia inserir as 1000 linhas em média 7 segundos. E isso é que eu não sabia utilizar adequadamente o ADO.NET, se eu soubesse creio que seria mais rápido ainda.
Então amigo, fica ai a dica dos nossos amigos, é utilizar a tecnologia corretamente, e aproveitar o máximo que ela pode nos oferecer.
Até mais.
Até mais.
Antigamente quando eu desenvolvia em VBA, eu estava fazendo um sistema que utilizava um banco em ACCESS mesmo, e então fiz um teste com os meus dados armazenados em MYSQL. Ao atualizar um único registro tinha uma diferença de 4 segundos, ou seja, cada registro demorava 4 segundos e já no MYSQL não dava nem dois direito. Lembrando que já aparentava essa diferença em VBA, já pensou isso em VB.NET, que sem dúvidas é mais rápido.
Outro teste também que já fiz aqui, foi tentar calcular a quantidade de dados inseridos em um determinado tempo, tinha um Datagridview com 8 colunas, e 1000 linhas, eu conseguia inserir as 1000 linhas em média 7 segundos. E isso é que eu não sabia utilizar adequadamente o ADO.NET, se eu soubesse creio que seria mais rápido ainda.
Então amigo, fica ai a dica dos nossos amigos, é utilizar a tecnologia corretamente, e aproveitar o máximo que ela pode nos oferecer.
Até mais.
Até mais.
Poxa, sou fã dos posts do Professor! 
Pena estar apenas de passagem.
_______________________________________________
Sem dúvida! Eu quando comecei também ia muito na empolgação de querer fazer logo, e desconsiderava pontos importantes sobre a tecnologia usada e por causa disso sofri muito com problemas que poderiam ser eliminados no inÃcio. Mas naquela época internet era um luxo e eu só tinha um livro velho de VB4, um 486 e conhecia 2 pessoas meio perdidas na profissão.
Hoje em dia pra quem quer começar, orientação e aplicativos gratuitos não faltam.
_______________________________________________
O autor disse que tem uma tabela com 100.000 linhas (até pro Access isso é muito pouco). é muito estranha essa lentidão. Seria bom vc explicar o cenário em que sua aplicação é utilizada pra ver se vai ser realmente necessário migrar a base de dados pra um SGDB.
Pena estar apenas de passagem.
_______________________________________________
Citação::
Concordo com o AJSO, mesmo programando com ferramentas atuais e de ponta... um sistema pode ficar bem lento por N fatores..
O negocio é saber usar a ferramenta que tens em maos !
Sem dúvida! Eu quando comecei também ia muito na empolgação de querer fazer logo, e desconsiderava pontos importantes sobre a tecnologia usada e por causa disso sofri muito com problemas que poderiam ser eliminados no inÃcio. Mas naquela época internet era um luxo e eu só tinha um livro velho de VB4, um 486 e conhecia 2 pessoas meio perdidas na profissão.
Hoje em dia pra quem quer começar, orientação e aplicativos gratuitos não faltam.
_______________________________________________
O autor disse que tem uma tabela com 100.000 linhas (até pro Access isso é muito pouco). é muito estranha essa lentidão. Seria bom vc explicar o cenário em que sua aplicação é utilizada pra ver se vai ser realmente necessário migrar a base de dados pra um SGDB.
Concordo com o facto de primeiro aprender mais sobre o Visual Basic 2008 (que sei agora que é vb.net 
) e depois partir para outras.
Só assim é que vou conseguir retirar toda a rentabilidade do meu projeto.
Na parte da lógica do código vou ter que mudar muita coisa pois acho que é isso que po.em o código lento!
Uma questão:
O facto de ter muiitas linhas de código isso influencia no desempenho do programa?
Eu para me ligar a minha base de dados utilizo o Provider ACE 12.0. é o mais indicado?
Que informações sobre o meu código tenho que vos dar para saber o que está a provocar a lentidão?
O tempo de carregamento do grid é de aproximadamente 3 segundos. Nº de Linhas: 30 Nº de Colunas 10
Então para já vou continuar a utilizar o Vb.net e o access para SGBD. Porque até não tenho muitos dados, comparado com o que ja falamos. 100 000 linhas é pouco né?!
Obrigado pessoal pela grande ajuda
) e depois partir para outras.Só assim é que vou conseguir retirar toda a rentabilidade do meu projeto.
Na parte da lógica do código vou ter que mudar muita coisa pois acho que é isso que po.em o código lento!
Uma questão:
O facto de ter muiitas linhas de código isso influencia no desempenho do programa?
Eu para me ligar a minha base de dados utilizo o Provider ACE 12.0. é o mais indicado?
Que informações sobre o meu código tenho que vos dar para saber o que está a provocar a lentidão?
O tempo de carregamento do grid é de aproximadamente 3 segundos. Nº de Linhas: 30 Nº de Colunas 10
Então para já vou continuar a utilizar o Vb.net e o access para SGBD. Porque até não tenho muitos dados, comparado com o que ja falamos. 100 000 linhas é pouco né?!
Obrigado pessoal pela grande ajuda
Citação::
O MS-Access(mdb ou accdb, ou seja, Jet 4.0 ou ACE) suporta sem problema algum até 2.3Gigabytes em dados, um pouco mais do que a Microsoft® garante. Em 1999, na empresa onde eu estava, a segunda maior do Brasil em sua área de atividade, utilizávamos um Access 97 com 1.8Gigabytes para administrar fretes marÃtimos, viagens, custeio de embarcações, conta gráfica (BACEN), avarias de contêineres e sobrestadia. Um único banco, e em três anos corrompeu uma única vez, por conta de um funcionário, que o acessou via MS-Office.
P.S. A empresa onde usávamos o Access 97 só o [Ô]abandonou[Ô] em definitivo em 2003, quatro anos depois de adquirirem as licenças de um SQL Server e nem mesmo implantar. Desse modo, respeitadas as boas regras de programação e manutenção da qualidade dos equipamentos, não falem mal desse [Ô]fusquinha[Ô], hehehe!
Finalmente alguem com conhecimento de causa, defende o tão criticado MS Access.
E olhe que falou bem do Access 97. Já vieram vários depois deste (2000, 2003, 2007) que garante melhor estabilidade.
O mal do brasileiro é achar que carro 1.0 não é carro. Na opinião da maioria carro que presta tem que ser um Honda civic, ou um Vectra 2.0. Compra um carro que atinge 200 km/h (ou indica para os seus clientes), para depois ficar presso no engarrafamento. e vai chegar da mesma maneira que o carro 1.0 chega.
Muitos neste fórum tem o hábito de recomendar [Ô]Canhão para matar mosquito[Ô].
[Ô]Não existe nada de complicado na Vida! Nós é que complicamos ela[Ô].
a julgar pelas perguntas, a resposta é pra ir estudar muito....
nao estou na segunda faculdade atoa
vc pode usar o mysql como foi sugerido, mas se a manipulacao do BD se manter a mesma q ao meu ver é o grande trunfo da sua lentidao...a lentidao vai ser exatamente a mesma com qq tipo de BD q usar....
so por curiosidade o acess de cep dos correios, tem mais de 150Mb, pelo menos 4 tabelas, algumas proximo de 700.000 linhas, ja utilizei, e fazendo a busca completa usando as 4 tabelas, a consulta era imediata
depende do seu codigo e pra isso so estudando....
fico tentando entender pq cria tanta dificuldade, se vc tem um acess compartilhado, quer dizer q esse pc onde o banco esta fica ligado o tempo todo q alguem for usar a aplicacao, so instalar ai o SGBD...
se ja ta com tanta dificuldade pra resolver migrar, pq ainda quer dificultar mais querendo inventar um servidor linux, se fazer codigo ta dificil, imaginar por pra rodar o SGBD a pleno vapor dentro de um ambiente linux, ta criando uma ilusao q o servidor pro BD tenha q ser algo fantastico como se ve em filmes, se vc usa em pc normal com esse acess compartilhado, instale ai o SGBD e seja feliz
nao estou na segunda faculdade atoa
vc pode usar o mysql como foi sugerido, mas se a manipulacao do BD se manter a mesma q ao meu ver é o grande trunfo da sua lentidao...a lentidao vai ser exatamente a mesma com qq tipo de BD q usar....
so por curiosidade o acess de cep dos correios, tem mais de 150Mb, pelo menos 4 tabelas, algumas proximo de 700.000 linhas, ja utilizei, e fazendo a busca completa usando as 4 tabelas, a consulta era imediata
depende do seu codigo e pra isso so estudando....
fico tentando entender pq cria tanta dificuldade, se vc tem um acess compartilhado, quer dizer q esse pc onde o banco esta fica ligado o tempo todo q alguem for usar a aplicacao, so instalar ai o SGBD...
se ja ta com tanta dificuldade pra resolver migrar, pq ainda quer dificultar mais querendo inventar um servidor linux, se fazer codigo ta dificil, imaginar por pra rodar o SGBD a pleno vapor dentro de um ambiente linux, ta criando uma ilusao q o servidor pro BD tenha q ser algo fantastico como se ve em filmes, se vc usa em pc normal com esse acess compartilhado, instale ai o SGBD e seja feliz
Citação:[Ô]...o acess de cep dos correios, tem mais de 150Mb, pelo menos 4 tabelas, algumas proximo de 700.000 linhas, ja utilizei, e fazendo a busca completa usando as 4 tabelas, a consulta era imediata
depende do seu codigo e pra isso so estudando...[Ô]
Vou [Ô]pegar carona[Ô].
Só para complementar, e no intuito de dar uma idéia de por onde passam as questões ligadas á desempenho, a base de CEPs completa (2010) possui na verdade pouco mais de 2.480.000 (isso, são mais de dois milhões, quatrocentos e oitenta mil!) registros, divididos em tabelas relacionadas. Deste volume, apenas uma pequena [Ô]amostra[Ô] sai para consumo nos aplicativos comercializados pela EBCT. O volume da base completa é próxima aos 800Mbytes (e inclui os mais de 5000 municÃpios brasileiros com seus respectivos códigos IBGE, as Unidades Federativas e outras informações relevantes ao Diretório Nacional de Endereços). Considere que um mesmo PRéDIO, ou um mesmo GRANDE USUÃRIO tem, ás vezes, 10 CEPs diferentes ou mais, enquanto uma cidade inteira, como Registros (SP), tem apenas um CEP. Há ainda os CEPs de Agências, de Caixas Postais etc. Ao todo, são esses quase dois milhões e meio de [Ô]ponteiros[Ô].
Esses dados, para que o tempo de resposta da consulta seja aceitável, foram adequados á uma estrutura relacional que é bem-suportada pelo MS-Access, pelo xBase (padrão dBase e similares), pelo Oracle e pelo MySQL. Ainda assim, uma consulta SEM os parâmetros mÃnimos (que miseravelmente são UF, Localidade e Logradouro, ou ainda o próprio CEP), com a base completa, demorava 19 segundos para completar os resultados. Desse modo, optou-se pela [Ô]regionalização[Ô] e pela [Ô]divisão por atividades[Ô] das bases distribuÃdas. Curiosamente, o Microsoft SQL Server demanda um delay bastante maior, comparativamente, com a mesma estrutura que os [Ô]concorrentes[Ô], ainda no quesito da base completa. Algo por volta de 31 segundos. Em todos, a base sendo local.
Após um bom trabalho de análise das consultas e do processamento, a solução foi de-normatizar as estruturas originais, compor massas de registros integrais e criar procedures para consulta em-linha. Isso feito, a demora da resposta passou para pouco menos de 12 segundos, no SQL Server, lembrando ainda, sem informar qualquer parâmetro de filtragem.
Ainda que a solução tenha sido satisfatória, ela não pode ser aplicada ao mecanismo MS-Access, pois resulta em um acréscimo de quase 20% no delay de resposta, e no MySQL, por volta de 12%. No Oracle, não fêz a menor diferença.
Bom, e o que isso tudo significa?
Na hora de desenvolver um aplicativo com acesso á dados, antes mesmo de esboçar um plano de desenvolvimento, é bom considerar com bastante atenção o objeto de negócio. Um bom banco de dados dispensa aplicativo, na maioria dos casos. O passo inicial é esboçar as informações que se pretende manter e consultar. Em seguida, buscar as informações derivativas e/ou complementares. E esse processo é relativamente lento, demanda várias fases de análise, implementação e homologação. Afinal, é quase certo que depois de criar suas estruturas de dados, uma ou outra informação surge como [Ô]esquecida[Ô].
O importante, nessa etapa, é que você consiga [Ô]conversar[Ô] com o banco de dados. E é isso deve mesmo ocorrer, é um diálogo mesmo, uma conversa. Quando ele, o banco de dados, conseguir responder á você, da forma como você espera, em todas as perguntas, só nesse ponto entra o planejamento do aplicativo. Você deve perguntar á ele, por exemplo, [Ô]- O cliente [ô]ABC[ô], com as informações [ô]X[ô], [ô]Y[ô], e [ô]Z[ô], que código têm?[Ô] O banco, por sua vez, deve responder [Ô]0[Ô], pois o cliente não está cadastrado. Você diz á ele [Ô]- Cadastre o cliente [ô]ABC[ô] e me retorne o código atribuÃdo á ele.[Ô]. O banco, agora, retorna [Ô]1[Ô]. Bem, essas são as primeiras conversas com seu banco de dados, e isso, ainda que pareça ineficiente ou improdutivo, vai lhe poupar muita dor de cabeça e pêrda de tempo. E como sabemos se está bom?
Com o tempo você vai perceber que pode (e deve) evoluir essa conversa, e bastante. Suponha um banco que administre as vendas de uma rede:
Quando você terminar com o banco, deverá poder comandar á ele (executar uma Stored Procedure) que, por exemplo:
[Ô]- Atribua 8% de redução ás comissões vinculadas á carteira profissional do vendedor que mais recebeu reclamações que geraram devolução sobre o produto [ô]ACME[ô], na linha [ô]Desenhos animados[ô], nas vendas á vista, apenas das lojas de conveniência e apenas as da [Ô]Região dos Lagos[Ô], entre Janeiro de 2008 e 15 de setembro de 2010, pelos próximos seis meses ou até completar 30% do valor de compra desses produtos á época de sua aquisição para esses estoques, e gere a folha de pagamentos deste mês para todas as lojas da rede.[Ô]
Regra geral, para saber quando está bom: Quando o banco cumprir a tarefa á contento, sem erros, de forma rápida e eficiente (e rápido, hoje, é com tempo jamais superior á 1 minuto para Winforms nas tarefas mais [Ô]dramáticas[Ô]), é nesse momento que ele estará bom para uso.
Aà você se depara um o outro lado: A IDE de usuário (ou GUI). O banco está bom, mas a tarefa acima, por exemplo, não há como demandar menos de 20 minutos, pois ela processa muitas tarefas. E o conceito de [Ô]demora[Ô] do usuário é bem diferente daquele do banco de dados. Assim, não é [Ô]malandragem[Ô], é metodologia, fazer com que a aplicação [Ô]dispare[Ô] um processo em background (dll ou exe, preferencialmente o último) para cumprir a tarefa, avise ao usuário que o processo foi iniciado e o libere para outras coisas. Quando o processo finalizar, ou se ocorrer algum erro, ele então [Ô]comunica[Ô] ao aplicativo [Ô]chamador[Ô]
que repassa a informação ao usuário por meio de uma janela de diálogo, com opções (tentar novamente, cancelar, opções alternativas etc).
Então, após um bom banco de dados, o esboço do aplicativo deve considerar também esses requisitos operacionais, nunca iniciar um processo sem retornos, possuir tratamento de erros (o que obrigatoriamente inclui a não-obrigatória imbecilidade do usuário), a facilidade de uso e, claro, de manutenção, além de uma interface que seja agradável. Em outras palavras, deve ser desenvolvido em etapas, por menor que seja, começando das funcionalidades e relegando aos passos finais o projeto da interface de usuário. Nesse último, cuidados especiais, também.
Um colega, há algum tempo, costumava ficar orgulhoso de telas que simplesmente não tinham espaços livres: Tudo era informação, em todos os lados haviam dados e atalhos para mais informações. De quadros á grades, de rótulos á gráficos, tudo era clicável, tudo abria mais janelas e mais informações, dezenas de telas com esse mesmo estilo, aplicações distintas com o mesmo design. Eram os [Ô]painéis de avião[Ô], como ele dizia.
Ele é um caso totalmente atÃpico. Voltados á atividade econômica, os sistemas dele traziam uma riqueza de informações atualizadas constantemente, e esse era o diferencial do mercado, um nicho em especial, um mercado muito particular, e era esse diferencial o que alavancava a tomada rápida de decisões, por usuários que conheciam muito bem esses dados e o que fazer com eles.
Infelizmente (ou felizmente, no meu ponto de vista pessoal), o usuário mediano de informática no mercado de hoje não se sente confortável com esse nÃvel de interface, e até se intimida bastante com telas que adotam esse padrão. E mesmo os [Ô]chefes[Ô] (gerentes, supervisores, diretores etc), sentem um [Ô]freio psicológico[Ô] em usar telas assim, pois ao cometer involuntariamente alguma [Ô]gafe[Ô], vão tornar público seu despreparo no uso da tecnologia. Com isso, essas telas podem ser lindas, mas são como aquele bibelô de porcelana da avó, ninguém pode brincar com eles, sua únicas finalidades são enfeitar as cristaleiras e juntar poeira.
Já a tendência das aplicações [Ô]hotJob[Ô] e [Ô]colaborate[Ô] ao que parece vai se firmar no mercado, ainda mais após a segunda metade de 2012, com o Windows 8 integrando os novos equipamentos. As [Ô]hotJob[Ô] são aplicações pequenÃssimas, que realizam uma, e apenas uma tarefa, e são distribuÃdas em pacotes ás dezenas, compondo um sistema mais complexo e normalmente proporcionando ao usuário atalhos comuns de acesso aos demais aplicativos do pacote. Com essa modalidade, as aplicações maiores e compostas por vários executáveis e DLLs podem começar á sofrer um re-escalonamento futuro.
As aplicações [Ô]colaborate[Ô] derivam principalmente da indiscutÃvel adoção das empresas ao uso de mecanismos de comunicação instantânea e de redes sociais. Esses aplicativos trabalham com bases de dados distribuÃdas e permitem, por exemplo, que á partir de um chat on-line se efetue o cadastro de um cliente, encaminhando-o ao Departamento Técnico, onde participa de uma video-conferência demosntrando alguns produtos, e de onde o cliente passa ao Depto. Comercial até o fechamento da compra. O detalhe neste caso é que todos os departamentos estão em cidades distintas, como também o cliente. Esse é um exemplo, mas não é o único. Uma classe de alunos, em uma aula, participa de uma entrevista, realizada em parceria por seu professor e um colega de uma universidade estrangeira, com um historiador grego, sendo que todos interagem com perguntas e respostas, compartilhamento de textos, livros, imagens e videos e toda a aula é registrada com classificação por tema, assunto, assim como os são os dados complementares, como a avaliação individual, o aproveitamento e o rendimento pessoal. Essa aula então pode ser revisada á qualquer momento, por qualquer outro aluno, de qualquer outra classe, em ambas as escolas. Isso é também um exemplo de aplicações [Ô]colaborate[Ô], que pode ser resumida da seguinte forma: Aplicativos [Ô]colaborate[Ô] são todos aqueles onde a produção de resultados e informações deriva da interação de vários agentes usuários, simultaneamente, independente de onde eles estejam, e que compartilham o registro dessas informações em qualquer momento.
é por ai professor, nao conhecia esse detalhe da base de cep completa, apenas conheco a comercializada nas agencias mesmo, a minha veio com 4 tabelinhas basicas
em meus aplicativos, qnd vai rodar isolado na estacao, opto por sqlce, agora qnd é em rede e acessos simultaneos, gosto muito do postgre, nao gosto do SQL server devido a ser um tanto pesado, nunca tinha ido a fundo e conhecido essa deficiencia em relacao a outras bases...
ao autor do topico q esta preocupado com um acess relaticamente pequeno, eu adoro programar em c, e trabalhar com arquivos pra guardar dados .dat, registros espalhados de todas as formas, como memoria hj em dia nao é problema nos pcs, o arquivo .dat pode ser carregado numa estrutura de vetor em memoria ram, e apresenta resposta imediata as consultas...
se esta preocupado com a qnt de linhas, mas de qq forma o crescimento é lento, nao se preocupe em manter sua base em acess, mas reveja seus conceitos, e melhore o codigo....o acess em si vc nao tem como melhorar.....
nos tempos do vb4 tive meu primeiro contato com um banco acess, usava buscas sequenciais, passava registro por registro no banco até encontrar o EOF, lembro-me na epoca uma tabela com pouco mais de 32000 registros, uma busca era intediante, porem eu estava comecando, e imaginava essa lentidao devido ao meu ver na epoca um banco enorme com 32000 registros....
conheci as querys de sql, parecia outro programa ja
mas pra isso, vc tem q cair no mundo e estudar
em meus aplicativos, qnd vai rodar isolado na estacao, opto por sqlce, agora qnd é em rede e acessos simultaneos, gosto muito do postgre, nao gosto do SQL server devido a ser um tanto pesado, nunca tinha ido a fundo e conhecido essa deficiencia em relacao a outras bases...
ao autor do topico q esta preocupado com um acess relaticamente pequeno, eu adoro programar em c, e trabalhar com arquivos pra guardar dados .dat, registros espalhados de todas as formas, como memoria hj em dia nao é problema nos pcs, o arquivo .dat pode ser carregado numa estrutura de vetor em memoria ram, e apresenta resposta imediata as consultas...
se esta preocupado com a qnt de linhas, mas de qq forma o crescimento é lento, nao se preocupe em manter sua base em acess, mas reveja seus conceitos, e melhore o codigo....o acess em si vc nao tem como melhorar.....
nos tempos do vb4 tive meu primeiro contato com um banco acess, usava buscas sequenciais, passava registro por registro no banco até encontrar o EOF, lembro-me na epoca uma tabela com pouco mais de 32000 registros, uma busca era intediante, porem eu estava comecando, e imaginava essa lentidao devido ao meu ver na epoca um banco enorme com 32000 registros....
conheci as querys de sql, parecia outro programa ja
mas pra isso, vc tem q cair no mundo e estudar
Tópico encerrado , respostas não são mais permitidas