---|Ветка была без названия|---

← →
kserg@ukr.net (2002-04-18 11:53) [0]

Привет всем.
Прошу, обясните мне в чём отличие 3-х нижеприведенных
способов обращения к полю и какой из способов более правильный
в плане экономии памяти
Query.Fieldbyname("Obozn").AsString
QueryObozn.AsString
Query["Obozn"]

Cпасибо.

← →
Reindeer Moss Eater (2002-04-18 11:57) [1]

Одинаково совершенно

← →
GenBr © (2002-04-18 12:00) [2]

Только в последнем случае возвращается значение не типа String, a Variant

← →
Shaman_Naydak © (2002-04-18 12:01) [3]

По памяти - эквивалентные конструкции..
По скорости - второй вариант предпочтительнее (НО! выявить это можно только БОЛЬШОМ цикле(

← →
kserg@ukr.net (2002-04-18 12:02) [4]

>Reindeer Moss Eater
Не совсем согласен.
К примеру, из своего опыта я обнаружил, что если поле= NULL,
то обращение Query["Obozn"] вызывает исключение, а вот
Query.Fieldbyname("Obozn").AsString - нет.

← →
Reindeer Moss Eater (2002-04-18 12:08) [5]

>kserg@ukr.net
А к расходуемой памяти это какое отношение имеет?

← →
kserg@ukr.net (2002-04-18 12:09) [6]

>Shaman_Naydak © (18.04.02 12:01)
А за счет чего появляется выигрыш в скорости ?
(у меня основная таблица содержит около 40полей)

← →
Reindeer Moss Eater (2002-04-18 12:11) [7]

Во втором варианте поле не ищется в памяти

← →
kserg@ukr.net (2002-04-18 12:12) [8]

>Reindeer Moss Eater (18.04.02 12:08)
Причем здесь "экономия памяти", если такой вызов вощще "криво" работает ?
Поэтому, стараюсь избегать таких обращений

← →
Val © (2002-04-18 12:13) [9]

Но оно должно быть статическим?

← →
Reindeer Moss Eater (2002-04-18 12:16) [10]

>kserg@ukr.net
экономия памяти здесь при том, что именно она волновала автора вопроса

← →
kserg@ukr.net (2002-04-18 12:17) [11]

>Val © (18.04.02 12:13)
>Но оно должно быть статическим?
Недопонял?..
Обясни, плиз

← →
Johnmen © (2002-04-18 12:21) [12]

Необходимо учитывать время на идентификацию поля и на преобразование типов.
1 вариант тратит время на идентификацию
3 вариант - на преобразование типа
2 наиболее оптимален по скорости, но не оптимален по удобоваримости :)

← →
Val © (2002-04-18 12:22) [13]

QueryObozn.AsString - для такого обращения к полю QueryObozn должно быть обьявлено в модуле, разве нет?

← →
kserg@ukr.net (2002-04-18 12:24) [14]

>Val © (18.04.02 12:22)
>QueryObozn.AsString - для такого обращения к полю QueryObozn должно быть обьявлено в модуле, разве нет?
Понял - согласен.

Reindeer Moss Eater (18.04.02 12:16)
Тогда второй

← →
kserg@ukr.net (2002-04-18 12:29) [16]

Reindeer Moss Eater (18.04.02 12:16)
Тогда второй

Если в программе много объектов полей, то persistent-поля (2) увеличивают размер хранимых ресурсов (dfm) в exe. Выигрыш по скорости по сравнению с 1 незначителен.
Скорее это вопрос удобства.
Раньше я придерживался варианта 2, теперь придерживаюсь варианта 1 (run-time поля), так как при изменении параметров поля в базе (например, ширины) или динамическом изменении текста запроса вариант 1 удобнее.
Однако во всех тек случаях, когда поля в базе стабильны и требуется дополнительное форматирование (DisplayFormat) или Align или русское название поля (DisplayLabel), предпочитаю использовать вариант 2.
Вариант 3 не использую вообще.

А с точки зрения памяти - все это совершенно неважно, так как основную память жрет сам набор данных, а не объекты TField, и неважно как возникли их свойства, на стадии разработки или в run-time.

Вариант 2 еще и обеспечивает контроль того, есть ли такое поле в наборе данных на этапе компиляции, а не выполнения, так же на этапе компиляции, а не выполнения контролируется тип поля. Он сымый быстрый, т. к. не тратится время на поиск поля в списке полей (а поиск этот осуществляется простым перебором).

1 вариант сам Borland считает почему-то устаревшим, и не рекомендует к использованию, хотя я бросаю на форму один компонент TQuery и потом динамически меняю текст запроса, при таком раскладе 2 вариант слишком трудоемок по сравнению с 1.

---|Ветка была без названия|--- Найти похожие ветки