Из книжки по 8.2 товарища Радченко.

       Запрос = Новый Запрос;
       Запрос.УстановитьПараметр("ТекущийДокумент", Ссылка);
       Запрос.Текст =
       "ВЫБРАТЬ
       | Дата
       |ИЗ
       | Документ.ВводНачальныхОстатковНоменклатуры
       |ГДЕ Ссылка = &ТекущийДокумент";

       Выборка = Запрос.Выполнить().Выбрать();
       Выборка.Следующий();


Неужели это быстрее чем Объект.Дата ?

суть то одна и та же

(0) в теории на больших выборках - быстрее

потому что Объект.дата - заставит закешировать весь объект, а запрос - только прочитает дату, и все

(2) На больших, где обращаться приходится к множеству полей - да, а когда одно поле.
Хотя - да. с (3) Согласен.

оператор:

дата = обьект.дата

затянет на клиент весь обьект и потом получит дату, а в обьекте может быть ТЧ на 10 000 строк или бинарные данные...

а вот по чему не сделать

дата = ссылка.дата

я не понимаю

(3) точно, вопрос именно в кеше сервера, и его вытеснении...

(5) ТЧ подтягиваться не будет

я думаю, проблема ваще не в том что Объект тянет весь объект.
а в том, что запросом получаются реальные данные, которые записаны.
если открыть док и поменять дату не записывая, то ваш "объект.дата" вернет новую дату.
а запрос старую.
как то так...

(7) ну бинарный реквизит на 100 метров с картинкой :)

(8) А иным способом получить хранимые в базе значения нельзя?

(5) "а вот по чему не сделать дата = ссылка.дата" - потому что тогда из БД будут считаны ВСЕ реквизиты

(0) это не столько быстрее, сколько правильнее...

(12) каков критерий "правильности"?

(13) у меня на подобные вопросы всегда один ответ: дорогу правильнее переходить на зеленый свет. кто не согласен, может переходить и на красный...

(14) неверно, переход на зеленый свет - не есть правильно с точки зреняи пешехода. С точки зреняи пешехода переход на зеленый свет + отсутствие авто мчащихся на зеленый свет.
.
поэтому правильнее на зеленый свет переходить именно потому, что не цвет зеленый, а что в это время машины стоять должны. т.е. существует достаточно внятный критерий "правильности" перехода на зеленый свет.
.
вопрос снова: каков внятный критерий "правильности" сабжа?

(15) Быстрее и таки правильнее. Запрос получает данные из БД, если их брать из объекта - есть вероятность, что реквизит изменился.
Кроме того, такой код можно легко перенести в другое место, если у тебя везде будет натыкано "Объект.Реквизит", то будешь потом переделывать.
Ну и вообще, есть методические указания, открой глаза и прочитай.

(15) я ж говорю: кто не согласен - сам себе злобный буратино. пусть переходит на красный. почему правильнее выбирать запросом в данном конкретном случае - ответ очевиден тому, кто понимает суть происходящего в том и другом случае...

(17) злой ты.. ;-)

Быстрее, при любом размере выборки.

(19) я имел ввиду, что есть места,  где разницей можно принебречь

(19) а почему быстрее?

(21) см. (11)

т.е. только за счет того, что чтение производится именно для конкретно указанного реквизита?

(23) не используется кеш и все механизмы, с ним связанные

(11) >>"а вот по чему не сделать дата = ссылка.дата" - потому что тогда из БД будут считаны ВСЕ реквизиты

Это точно?

(25) :) Да, точно. Стр. 41 в "проф разработке".

(0) код конечно быстрее отрабатывает и в 8.2 на тонком и веб-клиенте свои заморочки (код в (0) наверно тянет данные из текущей строки таблицы формы)... но я предпочитаю сначала написать код быстро и правильно (то есть обычно я б написал объект.дата), а уже потом заниматься производительностью, если нужно.

(14) если нужно перейти дорогу, то я ее просто перейду, если вдруг возникают проблемы (сбили пару раз например), то тогда только начну искать светофор, переход и прочее... может мне изначально нужно перейти дорогу, на которой машины то раз в месяц появляются

(16) от того, что напишешь ссылка.Дата или код в (0) связность не изменится, поэтому даже если я перенесу код в другое место, то он перестанет работать при некорректной "Ссылка" в обоих случаях... вот если из контекста тянуть данные (обращаться просто Дата), то связность увеличивается со всеми вытекающими

Вообще, в типовых на 8.1, при работе с формой, не считается зазорным получать данные "через точку"

РеализацияНаЭкспорт = ?(ЕстьДоговорКонтрагента, ?(ДокументОбъект.ДоговорКонтрагента.РеализацияНаЭкспорт = Истина, Истина, Ложь), Ложь);

а также использование тяжелых конструкций типа

ИмяТабличнойЧасти = Метаданные.НайтиПоТипу(ТипЗнч(СтрокаТабличнойЧасти)).Имя;

Не считается критичным. При записи-проведении другое дело.

(28) бугага! завязывай с игрухами, это опасно! в реале второго раза может и не быть....

(27) "но я предпочитаю сначала написать код быстро и правильно (то есть обычно я б написал объект.дата), а уже потом заниматься производительностью, если нужно." - видно не работал никогда в большом проекте с жестким контролем качества и штрафами за лаги...

(29) Если делать через запрос, то изменение потребуется только в одном месте - при установке параметра. В твоем варианте - везде.

(31) программирование немного не похоже на реальность... первый раз обычно ловится на тестировании
(32) а что есть большой проект? и почему эти принципы не подходит к большим проектам?

(0) Почитай ИТС: 'Особенности использования типов данных, предназначенных для манипулирования объектами базы данных' и 'В каких случаях использовать ссылку, запрос, выборку и объект'.
И Радченко по 8.2: стр. 440. Устройство кеша.

(33) в смысле везде? в одном месте, где идет обращение к дате через точку... если код в (0) вынесен в отдельным метод доступа, то и Ссылка.Дата тоже можно рассматривать как метод доступа

(32) штрафовать программиста за ошибки... да я б там сразу всех послал и ушел с такого проекта...

(37)+1000
Там и текучка дай боже - сталкивался  с подобными фирмами.
Реализовавали в всемером большой проект и никто не штрафовал - потому что сразу сказали - баги будут. Контролируйте данные. На это и есть отладка

>> Послал бы и ушел...

Да вот никто не берет...

(36) Тебе и правда нужен будет один реквизит объекта? Или все же несколько?
И вообще - на ИТС есть статья, в которой описываются рекомендации, потрудись ее прочесть.
(38) Тебя не штрафовать, тебя сразу гнать надо.

(37)
Ошибки - они разные бывают.

(0) ужасно, это методологические недоработки разработчиков.
пусть напишут нормальный геттер для реквизита (списка реквизитов).

Вот никогда не понимал в модуле проведения вот такой код (почти цитата):

...
ТекСклад =      Ссылка.Склад;
ТекКонтрагент = Ссылка.Контрагент;
ТекДоговор =    Ссылка.ДоговорКонтрагента;
...

Недоумение возникает на счет использования несколько раз конструкции Сссылка.Реквизит. Для чего? Ведь при проведении документ уже записан?

(40) ты всегда пишешь обращение к реквизиту какого либо объекта через запрос, а не через точку? в этой ситуации запрос vs через точку лично я вижу только плюс сл стороны запроса - быстрее отрабатывает, со стороны "через точку" - код ооочень простой и понятный и его легко можно будет модифицировать потом, при появлении проблем (про рефакторинг потрудись сам почитать что нить), если нужно...

Пример. Есть 2 программиста: П1 и П2. производительность абсолютно одинакова, задача поставлена абсолютно одинакова, но П1 каждую строчку кода пытается написать так, чтобы она работала быстрее (тратит при этом время на разработку + время на оптимизацию (Р + О)). П2 просто пишет код не заморачиваясь оптимизацией - время разработки Р. После того как П2 реализовал функционал и прогнал тесты он обнаружил, что узких мест в коде всего 20% от всего кода (правило 20/80), которые и нужно оптимизировать. Итого П2 потратит на разработку колвоСтрок * (Р + 0.2*О)), а у П1  колвоСтрок * (Р + О)). На выходе о обоих программистов одинаковые решения.


(41) вообще то не считаю обращение к реквизиту объекта через точку в общем случае ошибкой. иногда в каком либо контексте может быть, но не по умолчанию...

(44) безусловно, ты прав. но выбор способа решения сабжа зависит от понимания внутренних механизмов восьмерки...

Еще кстати встречал в книжке такого плана код:
в запросе:
ЧтоТо.Количество
ЧтоТо.Цена

А потом в переборе выборки результата:

Выборка.Количество * Выборка.Цена

А в запросе не эффективнее?

+ к (46) При этом поля по отдельности не используются

(46) для больших массивов, например

Для к = 0 ПО 1000 Цикл
  ЧтоТо = массивСсылок[к];
  ЧтоТо.Количество
  ЧтоТо.Цена
КонецЦикла;

будет тормозить не по-детски.

При варианте с Выборкой тормозить не будет.

Хм... Удивляюсь, что еще никто не послал автора :) в отладку - в замер производительности.

(44) "ты всегда пишешь обращение к реквизиту какого либо объекта через запрос, а не через точку?" - да.
Про производительность - бред. Атомный.

интересно как утверждение из (0) будет выглядеть на 8.2... ДокОбъект.Код все равно на сервере сидит

кстати 8.2 вполне может увеличить кол-во "плохого кода". Проще написать на клиенте с помощью "magic number" логику чем нырять за каждой мелочью на сервер

(51) запрос на тонком клиенте тож не особо работает, да и вообще ветка в рамках 8.2

(52) я для этих целей кэшируемый модуль использую

(54) это которых хранит результат? А как он все таки работает если в сигнатуре пользуются структуры?

(55) коллекции не использую просто, есть подозрение, что толку не будет от таких методов, даже кешируемых

(50) "Про производительность - бред. Атомный." и что бредового? это как бэ не я придумал, а вычитал у Макконнелла ( http://ru.wikipedia.org/wiki/Макконнелл,_Стив ), Кента Бека ( Kent Beck ) и Фаулера ( http://ru.wikipedia.org/wiki/Фаулер,_Мартин )  или они все ничего не понимают в программировании???

(подколка) Ооо... Данные господа изучали 1С? Не знал :)

(58) данные господа изучали программирование в целом, а не конкретный инструмент... Вы же не будете учится готовить по инструкции к микроволновке?

Тонкий юмор не дощел :)

"безусловно, ты прав. Но выбор способа решения сабжа зависит от понимания внутренних механизмов восьмерки" ( Jolly Roger )

(48) Речь о выборке результатов запроса