banco de dados ou arquivo?
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á
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
Curtidas 0
Respostas
Joni Nunes
24/02/2006
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.
GOSTEI 0
Paullsoftware
24/02/2006
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:
use
fica bem mais rápido!
espero ter ajudado :wink:
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:
GOSTEI 0
Sourcecode
24/02/2006
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
Com 500.000 registro tá passando de hora de migrar pra um SGDB, recomendo sempre o firebird.
[]´s
GOSTEI 0
Piaum3
24/02/2006
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
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
GOSTEI 0
Aroldo Zanela
24/02/2006
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.
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.
GOSTEI 0
Piaum3
24/02/2006
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
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
GOSTEI 0
Bon Jovi
24/02/2006
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.
GOSTEI 0
Piaum3
24/02/2006
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
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
GOSTEI 0
Bon Jovi
24/02/2006
Crie um índice para ´codigo´ e outro índice para ´numTag´.
GOSTEI 0
Piaum3
24/02/2006
mais chave primária não é mais rápido que indice?
GOSTEI 0
Aroldo Zanela
24/02/2006
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].
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].
GOSTEI 0