Delphi - FieldByName.AsString - buena práctica

Question

He leído una publicación de blog (en este momento no puedo encontrar el enlace) donde el autor decía que es más rápido asignar una variable local que usar ADOQuery.FieldByName (' ... '). asString o TSQLQuery.FieldByName (' ... '). asString, al analizar una consulta completa con varios miles de registros. No veo la diferencia entre

var aLocalField: TField; 
.... 
aLocalField := ADOQuery.FieldByName('...'); 
.. 
ShowMessage(aLocalField.asString) 

y utilizando directamente

ShowMessage(ADOQuery.FieldByName('...').asString); 

Blog post no decir nada sobre el tipo de base de datos o la versión de Delphi. ¿Esta solución está relacionada con una u otra (y no estoy hablando de sistemas de bases de datos oscuros/personalizados)?

Answer 1

No hay una diferencia de rendimiento notable entre los dos. Espero que lo que encontraron fue la diferencia entre

DataSet.First; 
while not DataSet.Eof do 
begin 
    ProcessValue(DataSet.FieldByName('Field').AsString); 
    DataSet.Next; 
end; 

frente

Field := DataSet.FieldByName('Field'); 
DataSet.First; 
while not DataSet.Eof do 
begin 
    ProcessValue(Field.AsString); 
    DataSet.Next; 
end; 

Si es así, este último es más eficiente porque FieldByName es un (relativamente) la función lenta. Si no necesita llamarlo más de una vez, no lo llame más de una vez.

Answer 2

Lo que tiene sentido es la siguiente:

1. Si usted tiene una clase (como por ejemplo un TForm) no es una función local, ya sea persistentemente crear los campos que evite el costo de las operaciones de búsqueda repetida (FieldByName).

2. Si no utiliza los campos persistentes (en dfm), puede hacer una búsqueda una vez en tiempo de ejecución, y evitar el costo de buscarla repetidamente, si se usa ya sea (a) más de una vez el contexto de una función única, o (b) donde podría buscarse una vez cuando se ejecuta la consulta, y almacenarse en un campo protegido de un objeto, de modo que pueda reutilizarse durante la vida de la consulta o el objeto, según sea apropiado.

Su ejemplo artificioso tiene un beneficio cero, pero yo creo que las repetidas operaciones de búsqueda de campos cuando se desperdician estas búsquedas lógicas repetidas, son tal vez una cosa digna de mencionar como "desperdicio".

veo código así todo el día, y me vuelve loco:

procedure TSomething.DoSomething; 
begin 
    fDataset.FieldByName('X').AsString = fDataset.FieldByName('X').AsString+'Y'; 
end; 

El código anterior se hace menos legible por tales repeticiones, y tales preocupaciones de legibilidad, así como las preocupaciones de comprobación de errores son por qué evitaría lo anterior, y en lugar de tener un campo fX:TField:

TSomething = class(TBaseClass) 
    protected 
    fDataSet:TDataSet; 
    fX:TField; 

end; 

Ahora podemos escribir

fX.AsString := fX.AsString + 'Y'; 

Creo que las personas se preocupan demasiado por el rendimiento y no por la calidad, y las subexpresiones largas repetidas son un signo de "falta de calidad" y "falta de pensamiento" tanto como de "falta de preocupación por el rendimiento".

Answer 3

FieldByName use simple-search. si desea elegir más de un campo. este código es mejor

// Same Text in StrUtils(unit) 
for I:=0 to DataSet.Fields.Count-1 do 
begin 
    if SameText(DataSet.Fields[I].FieldName,'Field1') then 
    Field1:=DataSet.Fields[I] 
    else if SameText(DataSet.Fields[I].FieldName,'Field2') then 
    Field2:=DataSet.Fields[I]; 
end; 
DataSet.First; 
while not DataSet.Eof do 
begin 
    ProcessValue(Field.AsString); 
    DataSet.Next; 
end; 

Answer 4

Leer:

• FieldByName, FindField: too convenient to be honest
• FieldByName, or why a Profiler is your friend