banco de dados ou arquivo?

24/02/2006

boa tarde,

preciso de uma ajuda...

tenho uma tabela de banco de dados, que tem aproximadamente 500000 pra mais, só que essa tabela eu preciso das respostas instantaneamente, ai que mora a minha dúvida.

tem algum jeito de fazer isso sem ser com banco de dados? tipo um arquivo em binário ou algo do tipo?

fico no aguardo e agradecendo desde já


Piaum3

Respostas

24/02/2006

Joni Nunes

Olá, vc poderia ser mais específico, vc tem o que exatamente e precisa do que exatamente ?, creio que com essas informações fique mais fácil de tentar-mos ajudar.


Responder Citar

24/02/2006

Paullsoftware

kra para resolver esse seu problema procure usar consultas SQL com SELECT e traga somente o que vc está precisando, eu não acho que 50000 seja um numero grande, já que tenho uma aplicação onde a minha base já tem quase 500Mb tenho uma tabela de protocolo onde essa tabela possui mais de 200000 registros, e a atendente inicia um nova operação sem esperar nada pq não trago as informações não desejadas para minha tela.
pense nisso não sei como vc está tratando os seus dados mais procure filtrá-los, se já faz isso, procure fazer mais impondo alguns critérios...
ao invés de:
SELECT * FROM TABELA

use
SELECT NOME, END,FONE FROM TABELA
WHERE CRITERIO

fica bem mais rápido!

espero ter ajudado :wink:


Responder Citar

24/02/2006

Sourcecode

piaum3, olha você não é o primeiro que eu vejo com receio de migrar pra um banco de dados de verdade pelo fato da ´demora´ maior, o que o pessoal não quer entender é que vamos supor um dia cai a força e corrompe 200000 registros porque o você não tinha um SGDB pra segurar as falhas e não tem uma ferramenta que fixe os erros causados, agora eu pergunto pra você, o que é melhor, levar uns segundos a mais pra realizar a consulta ou arriscar usar um meio inseguro de armazenamento de dados e correr o risco de um dia perder boa parte das informações armazenadas? Outro coisa que eu sempre noto é que quem usa paradox, DBF entre outros e começa a usar um SGDB tem sempre uma idéia errada dos comandos SQL, a velha mania do SELECT * FROM TABELA, como o PaullSoftware disse, primeiro, filtre somente o que for necessário com a cláusula WHERE, segundo traga somente os campos que for precisar SELECT CAMPO1, CAMPO2 FROM TABELA, assim sua consulta será 3000x mais rápida do que com arquivos de dados.
Com 500.000 registro tá passando de hora de migrar pra um SGDB, recomendo sempre o firebird.

[]´s


Responder Citar

26/02/2006

Piaum3

então não são 50000 e sim 500000 registros...

eu uso o select codigo from tabela where nome = ´tiago´ por exemplo, pego apenas os campos que me interessam...

eu uso o mysql... é um banco bom concordam?

e não teria problema de perder dados nesse caso porque esses 500000 registros, são adicionados todos os dias entendeu... então não teria problema...

algúem manja como deixar mais rápido as consultas... nesse caso preciso de velocidade de resposta


Responder Citar

26/02/2006

Aroldo Zanela

Colega,

Acredito que a primeira medida de ´tuning´ para aumentar o desempenho de sua aplicação, possa ser obtido por meio da criação de índices para as colunas que são utilizadas na cláusula WHERE.


Responder Citar

26/02/2006

Piaum3

então mais a aminha consulta é por primary key cara...

select codigo from tabela where tag = 1234

tanto codigo quanto tag são primary key e demora quase um segundo para obter uma resposta

para você ter uma idéia é software de rodovia onde carros passam a mais de 50km/h tem que ser muito rápido para liberar


Responder Citar

26/02/2006

Bon Jovi

tanto codigo quanto tag são primary key

Chave composta? Então crie um índice separado para cada campo.

Se não for isso, informe qual SGDB está usando, script da tabela, qual forma de acesso está usando, etc. Quanto mais detalhes melhor, senão fica difícil.


Responder Citar

01/03/2006

Piaum3

banco de dados utilizado MYSQL 4.18.

abaixo segue o script da tabela

# Host: localhost
Database: pedagio_dersa
Table: ´cadtagdet´

CREATE TABLE ´cadtagdet´ (
´codigo´ bigint(20) NOT NULL auto_increment,
´tipo´ varchar(100) NOT NULL default ´´,
´idPaisEmissor´ varchar(4) NOT NULL default ´´,
´idEmissorTag´ varchar(5) NOT NULL default ´´,
´numTag´ int(11) NOT NULL default ´0´,
´placaVeiculo´ varchar(7) NOT NULL default ´´,
´catVeiculo´ char(2) NOT NULL default ´´,
´operacao´ char(1) NOT NULL default ´´,
´diaPagto´ char(2) NOT NULL default ´´,
´meioPagto´ char(2) NOT NULL default ´´,
´statusPassagem´ tinyint(4) NOT NULL default ´0´,
´formaPagto´ char(3) NOT NULL default ´´,
´cadastro´ varchar(100) NOT NULL default ´´,
´dataCadastro´ varchar(100) NOT NULL default ´´,
PRIMARY KEY (´codigo´,´numTag´)
) TYPE=MyISAM;

a forma de conexão é o DBEXPRESS utilizando os seguintes componentes.

SqlConnection --> para conexão com o banco de dados.
sqlQuery --> para consultas, inserções e demais.

sendo que este último, ele é criado na hora de execução e assim que terminada a execução é dado um .free.

sem mais e agradecendo


Responder Citar

01/03/2006

Bon Jovi

Crie um índice para ´codigo´ e outro índice para ´numTag´.


Responder Citar

01/03/2006

Piaum3

mais chave primária não é mais rápido que indice?


Responder Citar

01/03/2006

Aroldo Zanela

Colega,

Os SGBDRs implementam a ´indexação´ da chave primária de diferentes maneiras e normalmente são otimizadas para serem muito rápidas mesmo. Entretanto, a indicação do colega é totalmente válida para evitar o ´table scan´. Mesmo assim, o MySQL possui ´mecanismos´ de tuning para [url=http://dev.mysql.com/doc/refman/5.0/en/how-to-avoid-table-scan.html]forçar o uso de índice[/url].


Responder Citar