[Artigos]  Entenda por que Não Devemos usar FieldByName Publicado por rboaro : Segunda, Fevereiro 13, 2012 - 06:16 GMT-3 (1968 leituras)  21 Comentários    Enviar para um amigo    Versão para impressão Salve Galera!!! Essa questão de Fields[indice] ou FieldByName, é sempre polêmica, mas na minha opinião quem ler esse artigo com atenção irá abolir o uso do FieldByName em suas aplicações, assim como eu ja fiz a vários anos. Concordo que com FieldByName o código fica bem mais fácil de ser entendido. Da mesma forma sabemos que precisamos ter muito mais atenção ao usar Fields[Indice] para não passar o índice errado e fazer bobagem. Confesso que quando parei para analisar os dois métodos era adepto do FieldByName, mas depois de analisar o Fonte do Delphi, mudei de idéia e aboli o uso do FieldByName. Sendo assim vamos analisar o fonte e entender o que o Delphi precisa fazer em um caso ou em outro. Assim terei argumentos para convencê-los a usar sempre Fields[Indice]. "Implementação do FieldByName:" function TDataSet.FieldByName(const FieldName: string): TField; begin Result := FindField(FieldName); if Result = nil then DatabaseErrorFmt(SFieldNotFound, [FieldName], Self); end; Bom, até agora nada de mais. Mas vamos olhar como é implementado o método FindField: "Implementação do FindField:" function TDataSet.FindField(const FieldName: string): TField; begin Result := FFields.FindField(FieldName); if (Result = nil) and ObjectView then Result := FieldList.Find(FieldName); if Result = nil then Result := FAggFields.FindField(FieldName); end; Tenho certeza que até aqui ainda não os convenci, vamos então analisar agora o código do FindFields do Objeto FFields que é do tipo TField "Implementação do FindFieldsdo Objeto em FFields" function TFields.FindField(const FieldName: string): TField; var I: Integer; begin for I := 0 to FList.Count - 1 do begin Result := FList.Items[I]; if AnsiCompareText(Result.FFieldName, FieldName) = 0 then Exit; end; Result := nil; end; Observando o código acima, vamos pensar na seguinte situação. Imaginem que temos um dataset com 20 campos e temos na posição 20 um campo calculado com o qual precisamos fazer uma soma do tipo: "Campo calculado na posicao 20:" valor := 0; while not DataSet.Eof do begin Valor := valor + DataSet.FieldByName('campo_calculado').asCurrency; DataSet.Next; end; Se tivermos neste DataSet 100.000 registros, teremos que passar pela linha de código == Valor := valor + DataSet.FieldByName('campo_calculado').asCurrency; == 100.000 vezes. Um processamento razoável. Mas e o FieldByName? Observem que na implementação do método FindField da classe TField é utilizado um for de 0 até o número de campos para se encontrar o campo desejado e assim retornar o valor. Sendo, o nosso campo desejado, o campo de número 20, cada chamada de FieldByName - em nosso caso - ocasionaria um processamento de uma repetição 20 vezes até que o campo seja encontrado. Agora vamos fazer uma conta simples: 100.000 registros x 20 vezes (FieldByname) = 2000000 instruções processadas. Tenho certeza que vocês concordam comigo que é muito. Mas qual a solução? Fields[20]? Vamos ver a implementação da classe TFields para ver como o mesmo processa a instrução "Implementação em TFields:" Fields[indice]: TFields = class(TObject) private FList: TList; ... protected ... function GetField(Index: Integer): TField; ... public ... property Fields[Index: Integer]: TField read GetField write SetField; default; end; Podemos ver que Fields é uma property indexada, com certeza é mais rápido que o método "for" do FieldByName mas vamos mais a fundo. Vamos dar uma olhadinha no método de acesso GetField: "Metodo GetField:" if FSparseFields > 0 then begin if Index >= FSparseFields then DatabaseError(SListIndexError, DataSet); Result := FList[0]; Result.FOffset := Index; end else Result := FList[Index]; Reparem quem em nosso caso, que apenas a linha Result := FList[Index]; será acionada utilizando um TList onde são armazenados os campos de um DataSet. E como será a implementação da propriedade que define os itens de um TList? "Implementação do TList" TList = class(TObject) private FList: PPointerList; ... protected function Get(Index: Integer): Pointer; ... public ... property Items[Index: Integer]: Pointer read Get write Put; default; ... end; Por fim chegamos ao método de acesso Get da property items da classe TList: "Método Get da propriedade itens de TList:" function TList.Get(Index: Integer): Pointer; begin if (Index < 0) or (Index >= FCount) then Error(@SListIndexError, Index); Result := FList^[Index]; end; Observem a diferença. Aqui se trabalha com Ponteiros para a localização do campo desejado. Sendo assim, o processamento desta instrução terá peso 1, mesmo que tenhamos 20 campos em nosso DataSet. Agora vamos pensar na conta que fizemos anteriormente. 100000 registros x 1 vez (Fields[indice]) = 100000 instruções processadas. Olha que diferença entre executar 2000000 de instruções e 100000. Por isto digo, dentro de laços envolvendo um campo de um DataSet com vários campos, pensem bem se vale a pena utilizar valor := 0; while not DataSet.Eof do begin Valor := valor + DataSet.FieldByName('campo_calculado').asCurrency; DataSet.Next; end; ou valor := 0; while not DataSet.Eof do begin Valor := valor + DataSet.Fields[20].asCurrency; //campo_calculado DataSet.Next; end; Mas vamos deixar a coisa mais feia ainda, pensem nisso: FieldByName('A').asInteger := ((FieldByName('B').asInteger + FieldByName('C').asInteger)/ FieldByName('D').asInteger) * FieldByName('E') Isto para 1000 registros, em um DataSet com 5 campos (sendo muito otimista) daria no pior caso: 1(A) x 2(B) x 3(C) x 4(D) x 5(E) x 100 = 120000 instruções processadas Agora transportem esta situação para um DataSet com um pouco mais de campos e um pouco mais de registros. Na minha opinião inviável. Qual a maior dificuldade de usar Fields[indice]? A legibilidade do código? Pois bem, nada que um comentário não resolva Field[indice] // refere-se a campo tal.. Espero ter esclarecido essa questão. Abraço e até a próxima!

Comentários

Ordem:  Os mais antigos primeiro Os mais recentes primeiro Melhores primeiro

Comentários pertencem aos seus respectivos autores. Não somos responsáveis pelo seus conteúdos.

por: morfiuz (adrylb@gmail.com) : Fev 13, 2012 - 11:00 (Informações sobre o membro | Enviar uma mensagem) http://l2alone.com.br

é por isso que opto por usar TUpdateSQL e criar os TFields na TQuery, alem do código ficar legível, não corro risco de errar ao chamar um FieldByName, muito menos deixar o meu código sujo usando Fields[index]... Se acoplar os DBEdits no formulário usando TUpdateSQL, minhas consultas dependem ainda menos de código! Se existe o objeto para ser instanciado pra que "reinventar a roda" rescrevendo tudo de novo? Mas gostei da comparação apesar de que o processamento hj em dia é bem mais livre... Aonde um simples select, ou update de 1000 registros não leva mais de 0,03ms! Abraços

[ Comentários não permitidos para usuários anônimos. Por gentileza, registre-se ou conecte-se ao sistema

por: adriano_servitec (adriano_servitec@hotmail.com) : Fev 15, 2012 - 09:05 (Informações sobre o membro | Enviar uma mensagem) http://http://

Concordo plenamente com o colega weberdamasio. Já discuti o uso de fields na empresa, mais por causa do problema acima citado, ficou decidido o uso do fieldbyname mesmo.

[ Comentários não permitidos para usuários anônimos. Por gentileza, registre-se ou conecte-se ao sistema



por: leonammaia (leonam@beginsoft.com.br) : Fev 15, 2012 - 10:18 (Informações sobre o membro | Enviar uma mensagem)

Ao ler o artigo percebi um exagero enorme do autor. A performance não está no uso do FieldByName e sim em usá-lo dentro de um "laço". O ideal é criar uma variável externa ao "laço" com o valor do campo e utilizar essa variável dentro do "laço". Outro aspecto é usar o Fields[i] e colocar um comentário ao lado. O código fica muito poluído com tantos comentários. Na minha opnião o uso do FieldByName é ainda a melhor opção.

[ Comentários não permitidos para usuários anônimos. Por gentileza, registre-se ou conecte-se ao sistema



por: leonammaia (leonam@beginsoft.com.br) : Fev 15, 2012 - 10:21 (Informações sobre o membro | Enviar uma mensagem)

Ao ler o artigo percebi um exagero enorme do autor. A performance não está no uso do FieldByName e sim em usá-lo dentro de um "laço". O ideal é criar uma variável externa ao "laço" com o valor do campo e utilizar essa variável dentro do "laço". Outro aspecto é usar o Fields[i] e colocar um comentário ao lado. O código fica muito poluído com tantos comentários. Imagine alterando a posição dos campos dentro do ClientDataSet? mudou o código todo e o trabalho de alterar os índices do Fields[i]. Atualmente 99% dos usuários possuem boa máquinas, então o consumo de processamento do FieldByName se torna imperceptível e muito mais vantajoso falando em manutenção do software. Na minha opnião o uso do FieldByName é ainda a melhor opção.

[ Comentários não permitidos para usuários anônimos. Por gentileza, registre-se ou conecte-se ao sistema



por: Toniran (toniran@ig.com.br) : Fev 15, 2012 - 10:34 (Informações sobre o membro | Enviar uma mensagem) http://http://

Resolução do Problema do FieldByName em Loop. Apenas uma questão de utilizar os recursos da linguagem e ponteiros/referência. begin var Valor: Double; Field: TField; begin Valor := 0; Field := DataSet.FieldByName('NomeDoCampo'); //Executa o FieldByName apenas uma vez. while not DataSet.Eof do begin Valor := Valor + Field.AsCurrency; //campo_calculado DataSet.Next; end; Simples, prático e funcional.

[ Comentários não permitidos para usuários anônimos. Por gentileza, registre-se ou conecte-se ao sistema



por: gsoft (suporte@gsoftwares.com) : Mar 21, 2012 - 05:39 (Informações sobre o membro | Enviar uma mensagem)

Acho que esse seu exemplo foi fantástico Torinan!

[ Comentários não permitidos para usuários anônimos. Por gentileza, registre-se ou conecte-se ao sistema



por: gassis (gassis@cmnetsolucoes.com.br) : Mar 22, 2012 - 10:48 (Informações sobre o membro | Enviar uma mensagem)

Muito bom o exemplo que deu. Mas acho que se aplica quando for utilizar poucos campos do DataSet. Na prática dificilmente funciona assim. Se instanciarmos vários campos, aloca muito espaço em memória

[ Comentários não permitidos para usuários anônimos. Por gentileza, registre-se ou conecte-se ao sistema



por: breite (breite@msn.com) : Fev 19, 2012 - 11:16 (Informações sobre o membro | Enviar uma mensagem) http://

Concordo plenamente! Em situações onde existe muitos registros para serem computados, é uma boa saída o uso dos índices. Entretanto dizer: "Entenda por que Não Devemos usar FieldByName ..." é uma forma equivocada de expressar sua opinião. Exitem casos e casos, sou a favor de usar as duas formas!!!

[ Comentários não permitidos para usuários anônimos. Por gentileza, registre-se ou conecte-se ao sistema



por: chips90 (dennis.alves18@gmail.com) : Ago 04, 2012 - 02:16 (Informações sobre o membro | Enviar uma mensagem)

Concordo com o colega breite, é como: ..."Não usarás GOTO"... É claro que há situações e situações, depende da finalidade, da frequencia da manutenção, se a query será reaproveitada entre outros fatores não adianta querer citar uma "regra", porque no final das contas, o programador tem que se adequar com a finalidade do código.

[ Comentários não permitidos para usuários anônimos. Por gentileza, registre-se ou conecte-se ao sistema

por: Kirk_guitar (artur_alencar@hotmail.com) : Fev 28, 2014 - 05:35 (Informações sobre o membro | Enviar uma mensagem) http://

Concordo! No ERP que temos aqui na empresa eu faço cálculos e loops diretamente na query usando FieldByName e não acho o processamento lento. Acredito que o processamento se tornaria lento usando FieldByName apenas se fossemos pegar todos os dados de uma tabela e passar para outra tabela usando duas querys. Mas como na maioria dos casos não é isso que acontece, então... Por exemplo: eu tenho uma tabela de itens de pedido com uma média de uns 40 campos. Dou insert nesta tabela usando FieldByName('campo').AsAlgumaCoisa := outraquery.FieldByName('campo').AsAlgumacoisa. Mas faço isso só para alguns campos da tabela de itens (uns 5 ou 6). Porque o resto são resultados de cálculos feitos com outras variáveis. Então na maior parte dos códigos eu tenho isso: FieldByName('campo').AsAlgumaCoisa := valorDaVariavel. Levando em conta que tenho 40 campos( e que nem sempre aquele campo em questão vai ser o último da tabela), e que estou inserindo 50 itens, vou ter no final 40 x 50 = 2000 execuções de processo. Isso para computadores de hoje em dia não representa muita coisa...rsrsrs

[ Comentários não permitidos para usuários anônimos. Por gentileza, registre-se ou conecte-se ao sistema

Copyright© 2001-2016 – Active Delphi – Todos os direitos reservados