Что лучше использовать?

А не монописуально?

(0) Смотря для чего.

голосовалки не хватает..

Согласен с (2).

первое возвращает ТЗ - второе структуру.

(2) я знаю что срез последних вернет мне одну строку стоит ли в этом случае использовать получить последнее? Или лучше шаманить с таблицей значений?

(0)
Только явные запросы.
Объектная модель - от лукавого.

(7) Только прямые запросы. Запросы 1с - от лукавого.

(8) добавьте дополнительное поле, заполняйте его через триггер, остально от лукавого:
http://naf2000.blogspot.ru/2013/09/1-8_11.html

(9) Только Excel, остальное от лукавого

(9) курто, чё

(10) только счеты, остальное от лукавого

Да чё там, только вычисления в столбик.

Не, ну вот реально. Вообще не вижу смысла в объектной модели для получения данных, если только это не динамическая выборка.

Завтра понадобится какие-нить сопутствующие данные выбрать, и что? Придется плодить обращения к БД или переписывать на тот же запрос. Лучше уж сразу, чтобы два раза не вставать.

(14)
Динамическая выборка - это как?

(15) А если завтра не понадобится?
Зачем два раза вставать?
А если сразу писать тот же запрос, а завтра понадобится, это как-то облегчит работу?

(16) Объектная выборка справочников и документов получает данные из БД по принципу динамического списка - порционно. Может быть удобно для обработки очень больших объемов.
(17) А если не понадобится, то как минимум не надо запоминать лишние методы. Если понадобится - конечно облегчит. Получить доп.реквизит через точку или соединение воткнуть всяко быстрее, чем с нуля этот же запрос рисовать. Да и вообще объектная модель очень редко когда сейчас оптимальна даже на старте. Во всех алгоритмах пытаешься за один-два запроса все нужные данные вытащить, чтобы минимизировать обращения к БД. Объекты тут в пролете.

(18) Есть ситуации, когда целесообразно одно, есть - когда целесообразно другое. Поэтому, не вижу смысла фантазировать.

(19) Какая в опу фантазия? Суровая практика жизни.
Придумай мне хоть один случай когда объектный доступ будет целесообразнее. Если крупно повезет в эксплуатационном цикле - то он будет просто не хуже запроса. Поэтому не надо ля-ля.

(7)(8)(10) еретики, только береста!

СрезПоследних победил!!!

(9) Спасибо. Иногда и от тебя можно услышать что-то полезное.

(23) Сомнительная польза.
10-15%, хотя время выполнение тестов подозрительно мало (для тестов). Фиг его знает, чего на более крупных выборках покажет.

(24) А мы проверим. Есть у меня такой РС, идеально подходящий для этого.

(21) Каменные таблички, остальное от лукавого

(25) Отлично. Пост по итогам будет?

угу

(18)
"Объектная выборка справочников и документов получает данные из БД по принципу динамического списка - порционно. Может быть удобно для обработки очень больших объемов."
А выборка из результата запроса разве не так работает?
Она тоже не вся получается, а порционально.
Вот только результат, скорее всего, хранится на сервере приложений. С объектной моделью, скорее всего, тоже именно так и происходит. И ничем выборка по объектной модели не отличается.

(29) Отличается.

(30)
Чет не верю я тебе.

(31) Я - вру?

(32)
Откуда мне знать? А может и не врешь, а ошибаешься?

(33) Я почти не ошибаюсь. Счет идет на единицы за 7 лет.

(28) Только того этого. С блокировками возможны вопросы. Надеюсь, у тебя туда конкурентно не фигачат в больших объемах.
(31) Зря не веришь.

(34)
Тем не менее, вероятность есть.

(35) РС пишется раз в полгода, читается при каждом проведении.

Афтор статьи (9) ниасилил ее до конца.
Все не так однозначно :-)

Дополнительный индекс там не нужен, он никак не исползоваться не будет.
ииии, не факт, что будет быстрее...

Вся проблема в строчке
И &Дата МЕЖДУ ЦеныНоменклатуры.Период И ЦеныНоменклатуры.ПериодОкончания

которая мутируется в строчку
    ЦеныНоменклатуры.Период <= &Дата
    И ЦеныНоменклатуры.ПериодОкончания >= &Дата

именно оператор <= вызывает то, что сначало будет индексный поиск по полю Период и остаточный скан по ПериодОкончания.

Фсе. Это катастрофа :-)

Если вы делаете именно Срез, без отборов по измерениям - то выгода будет, если у вас немного отбором по измерениям - то выгода сомнительна, она будет из за отсутствия Сортировки, которая возникает там неявно.
Если у вас отборы почти по всем измерениям - будет проигрыш, так как эти отборы попадут в остаточный индексный скан.

Я, кстати, делаю именно Срез, поэтому мне - годно!

Прошу прощения.
В типовом Срезе отбор по измерениям (даже без пропусков) также попадает в остаточный индексный скан.

Да, метод Ненавижу выигрывает всегда.
Просто ему не надо добавлять индекс на ресурс.

итс:

Особенности методов менеджера регистра сведений

У объекта РегистрСведенийМенеджер имеется набор методов для доступа к данным регистра сведений.

Методы СрезПервых() и СрезПоследних() позволяют найти наиболее ранние и наиболее поздние записи по всем комбинациям измерений. При этом может быть установлен отбор записей. Методы возвращают таблицу значений, содержащую строки соответствующие найденным записям.

По своему действию эти методы аналогичны виртуальным таблицам СрезПервых и СрезПоследних. Их единственное преимущество перед использованием запроса - краткость записи.

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

Основным отличием описанных методов является то, что методы Получить(), ПолучитьПервое() и ПолучитьПоследнее() выдают значения одной записи, а методы СрезПервых() и СрезПоследних() позволяют получить несколько записей.

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

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

(43) А ты план запроса смотрел? Помоему и в том и в другом случае будет поиск по Периоду на меньше или равно

(45)  +100

(45) Да, именно я его и смотрел

И как фраза в (45) противоречит предыдущим моим фразам?

(0) Прямой SQL-запрос - не потратится время на преобразование 1С-запроса к запросу MS SQL ))).