DBEdits são bons componentes para grandes volumes de dados?

Delphi

01/10/2012

Bom dia.
Me disseram que componentes DbEdits, DBCombobox não são bons para Oracle e SQL Server, ainda mais se tiver grande volume de dados. Falaram-me tb que esses componentes dão muitos problemas..., é verdade? Vcs costumam usar esses componentes em bancos grandes?

Obrigada.
Yuffie

Yuffie

Curtidas 0

Respostas

Leonardo Xavier

Leonardo Xavier

01/10/2012

Cara tenho um sistema que atualmente utiliza 75 tabelas e utilizo estes componentes e nunca tive problemas com eles....
GOSTEI 0
Yuffie

Yuffie

01/10/2012

Me disseram que da problemas quando existem muitas pessoas conectadas ao banco. Que fica ocorrendo muito trafego de informações na rede, deixando congestionado. Eu me pergunto.., qual a diferença entre dar um next por uma query, e dar um next por uma tabela com dbedit? A query não vai ficar conectada constantemente tb?

Pois olhei em um tópico num site dizendo o seguinte:

"O uso do TDBEdit ou outro componente Data Ware, facilita muito a programação

Só tem um problema com ele:
Quando vc entra na tela que tem esse TDBEdit, vc terá que abrir a tabela a
qual esse
TDBEdit está ligado.
Agora imagine um sistema, rodando Clinet/Server, uma central de atendimento,
por exemplo.
300 usuários trabalhando o dia inteiro, na mesma tela, com 300 conexões
simuntâneas
com o banco de dados!!!

Se vc usar o TEdit, irá somente fazer a conexão quando der o INSERT, UPDATE
ou DELETE, sem
precisar da tabela ficar aberta o tempo todo, acarretando trafego
desnecessário na rede, etc..."
Fonte: http://www.mail-archive.com/delphi-br@yahoogrupos.com.br/msg01273.html

A query tb não ficará aberta no caso? E quando der next não tem que haver a conexão tb?
GOSTEI 0
Deivison Melo

Deivison Melo

01/10/2012

Não tem nada haver... Eles suportam grandes quantidades de dados sem problemas, e caso apresentarem problemas, verificar seu código pois o problema pode está no âmbito da programação!

Qualquer problema por favor postar o código para ser analisado!!

forte abraço e bons códigos!
GOSTEI 0
William

William

01/10/2012

Colega é tudo questão de gosto, tem programadores que não gostam de trabalhar com componentes DataWare por n motivos, já outros preferem esses componentes para agilizar o desenvolvimento.

Eu pessoalmente já desenvolvi usando esses componentes no início, mas hoje prefiro TEdit, TComboBox, TImage e etc.

Opção minha para controlar melhor a codificação, mas é gosto de cada um..
GOSTEI 0
Yuffie

Yuffie

01/10/2012

Disseram que os DBEdits foram originalmente desenvolvidos para bancos pequenos como Paradox... Já para bancos mais robustos, eles dão problemas...
Particularmente eu os acho mais práticos..., mas tenho essa preocupação em saber se realmente causam congestionamento na rede...
GOSTEI 0
Marcos Iwazaki

Marcos Iwazaki

01/10/2012

Olha amigo na minha opnião...
Se demora para abrir uma tela, não é pq tem dbware ou não.. e sim pq o dataset ta trazendo muitos dados.
se for o ClientDataSet tenta colocar RecordPacket = 30 por exemplo.
E sempre que possivel usar o DisableControls e EnableControls.

A vantagem de usar DBWare é bem clara... vc so liga ele no datasource e pronto, esta funcionando.

Agora se vc não quer usar DBware vc vai ter q fazer todo o controle braçal. É bastante coisa.
Se vc for usar o XE 2 ou XE 3 dae talvez até vale a pena por causa do Live binding.

Resumindo, na minha opnião não tem nada a ver essa demora usando DBWare.
GOSTEI 0
Alisson Santos

Alisson Santos

01/10/2012

A resposta é simples, a demora é devido a select que está passando na abertura de tela.
O retorno quando é lento é devido a quantidade de informação que está sendo retornado, o que tem que ser feito é customizar a select para que retorne rapido.
Sempre aconselho é utilizar o gerenciador de banco de dados e passar o select nele e verificar se o retorno é lento, se for, vai customizando para o retorno ser mais rapido.
GOSTEI 0
Yuffie

Yuffie

01/10/2012

Falaram também que softwares com DBEDIT faz com que as tabelas fiquem diretamente conectadas ao banco, se várias pessoas estiverem conectadas, podem ocorrer problemas. E com EDIT, é conectado ao banco apenas uma vez. Eu achei estranho isso pois, se quisermos percorrer os registros vamos dando next, e isso faz com que o sistema tenha que se conectar ao banco. Tb me disseram que esses componentes não seguem o modelo de programação em camadas.

Será que existe algum material didático que diga como esses componentes funcionam?
GOSTEI 0
Marcos Iwazaki

Marcos Iwazaki

01/10/2012

Se vai ter conexao direta com o banco isso depende do dataset que vc usa, por exemplo o ClientDataSet não faz conexão direta, ele trabalha todo em memoria somente no final q vc manda atualizar o registro.

Modelo de programação em camadas vc quer dizer separar Inteface, regra de negocio e banco, dae isso sim usando o dbware não seria possivel.

Eu acho que uma maneira legal de vc ver a diferença basica de usar os depois é fazer 2 telas de cadastro simples
uma com dbedit e outra com edit.

Dae vc ja vai ver na pratica a diferença.

Falaram também que softwares com DBEDIT faz com que as tabelas fiquem diretamente conectadas ao banco, se várias pessoas estiverem conectadas, podem ocorrer problemas. E com EDIT, é conectado ao banco apenas uma vez. Eu achei estranho isso pois, se quisermos percorrer os registros vamos dando next, e isso faz com que o sistema tenha que se conectar ao banco. Tb me disseram que esses componentes não seguem o modelo de programação em camadas.

Será que existe algum material didático que diga como esses componentes funcionam?
GOSTEI 0
Yuffie

Yuffie

01/10/2012

Marcos, estou usando o UniConnection.
GOSTEI 0
Marcos Iwazaki

Marcos Iwazaki

01/10/2012

Nunca usei este componente, mas faz um teste dom dbware e um sem dbware
Marcos, estou usando o UniConnection.
GOSTEI 0
POSTAR