Форум: "Базы";
Текущий архив: 2002.05.20;
Скачать: [xml.tar.bz2];
Вниз
---|Ветка была без названия|--- Найти похожие ветки
← →
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 должно быть обьявлено в модуле, разве нет?
Понял - согласен.
← →
Anatoly Podgoretsky (2002-04-18 12:27) [15]Reindeer Moss Eater (18.04.02 12:16)
Тогда второй
← →
kserg@ukr.net (2002-04-18 12:29) [16]>Val © (18.04.02 12:22)
>QueryObozn.AsString - для такого обращения к полю QueryObozn должно быть обьявлено в модуле, разве нет?
Понял - согласен.
← →
Anatoly Podgoretsky (2002-04-18 12:35) [17]Reindeer Moss Eater (18.04.02 12:16)
Тогда второй
← →
kaif (2002-04-18 17:19) [18]Если в программе много объектов полей, то persistent-поля (2) увеличивают размер хранимых ресурсов (dfm) в exe. Выигрыш по скорости по сравнению с 1 незначителен.
Скорее это вопрос удобства.
Раньше я придерживался варианта 2, теперь придерживаюсь варианта 1 (run-time поля), так как при изменении параметров поля в базе (например, ширины) или динамическом изменении текста запроса вариант 1 удобнее.
Однако во всех тек случаях, когда поля в базе стабильны и требуется дополнительное форматирование (DisplayFormat) или Align или русское название поля (DisplayLabel), предпочитаю использовать вариант 2.
Вариант 3 не использую вообще.
← →
kaif (2002-04-18 17:24) [19]А с точки зрения памяти - все это совершенно неважно, так как основную память жрет сам набор данных, а не объекты TField, и неважно как возникли их свойства, на стадии разработки или в run-time.
← →
evgeg (2002-04-18 22:56) [20]Вариант 2 еще и обеспечивает контроль того, есть ли такое поле в наборе данных на этапе компиляции, а не выполнения, так же на этапе компиляции, а не выполнения контролируется тип поля. Он сымый быстрый, т. к. не тратится время на поиск поля в списке полей (а поиск этот осуществляется простым перебором).
← →
IrenFD (2002-04-22 15:02) [21]1 вариант сам Borland считает почему-то устаревшим, и не рекомендует к использованию, хотя я бросаю на форму один компонент TQuery и потом динамически меняю текст запроса, при таком раскладе 2 вариант слишком трудоемок по сравнению с 1.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2002.05.20;
Скачать: [xml.tar.bz2];
Память: 0.49 MB
Время: 0.011 c
