Итак, снова поднимаю тему про параметры-отборы в виртуальных таблицах и их смысл.
Прочитав глас одинокого вопиющего Гения1С в http://www.forum.mista.ru/topic.php?id=282346&page=1, а также недовыясненные вопросы в http://www.forum.mista.ru/topic.php?id=432055, снова вопрошаю защитников отбора в виртуальной таблице:
Как использовать виртуальную таблицу (а зачем её вообще использовать, нельзя - не используй, спросите вы? А для чего еще, если не для быстроты запроса к "базовому" регистру этой таблицы), если нужен отбор по записи и - самое важное! - по ссылкам-реквизитам этой записи (пусть это будет склад из документа РТиУ, который в свою очередь, является документом-регистратором в РН Продажи (да даже неважно, в каком).
Непонятные отсылки к Книга знаний: v8: Виртуальные таблицы запросов (а что там сказано про параметры ВТ вообще и отборы в частности?) и к книге "Проф.разработка 1С8" (а нет там даже строчечки о том, что в отборах ВТ к РН НЕЛЬЗЯ использовать реквизиты и прочее, а только ИЗМЕРЕНИЯ самого РН - стр. 231 "Получение данных из РН и применение отборов к РН") - непонятны в силу "а к чему они были приведены?", и поэтому прошу их не давать.
Вот значит, что получается: документ как регистратор является костяком всего регистра (и должен являться ведущим и для производного от регистра - виртуальной таблицы с её итогами; ведущим - т.е. уж по нему-то я должен получать полную информацию при любом виде запроса к регистру), а отбор по его реквизиту я могу сделать только обыкновенным способом - через ГДЕ уже после формирования ВТ (тогда зачем она вообще нужна, если я могу и сам регистр запросить с точно таким же успехом).
Для наглядности, о чем речь - пример:

ВЫБРАТЬ
  РеализацияТоваровУслуг.Ссылка КАК РТиУСсылка,
  СУММА(Продажи.СуммаПродажОборот) КАК СуммаПродажОборот    
ИЗ
  РегистрНакопления.СуммаПродажОборот.Обороты(&НачПериода, &КонПериода, Регистратор, ) КАК СуммаПродажиОбороты
      ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
      ПО СуммаПродажОборот.Регистратор = РеализацияТоваровУслуг.Ссылка
ГДЕ РеализацияТоваровУслуг.Контрагент.Адрес = &Адрес

ИТОГИ
  СУММА(СуммаВзаиморасчетовОборот)
ПО
  ОБЩИЕ

И полностью согласен с Гением1С - зачем вообще нужен параметр-отбор в ВТ (да и само понятие ВТ - если смотреть на это с точки зрения требования быстродействия с одной стороны, и невозможности в данном случае пользоваться этим быстродействием - с другой), если я не могу прописать в её отборе:
РегистрНакопления.СуммаПродажОборот.Обороты(&НачПериода, &КонПериода, Регистратор, Регистратор.Контрагент.Адрес = &Адрес) КАК СуммаПродажиОбороты
- и только потому, что Регистратор - не ИЗМЕРЕНИЕ регистра накопления Продажи, а "всего лишь" РЕГИСТРАТОР! :)

Отвечаю Широкий: а причем тут SQL-запросы?
Это формирование запросов от 1С к SQL, и все восклицания - к 1С: почему так, и что теперь делать.

По разному. В некоторых случаях быстрее отработает условие в виртуальной таблице. Иногда перенос условия в ГДЕ ускоряет работу запроса
Другое

(0) вообще-то костяком, если уж речь пошла о костяках, является не регистратор, а как раз измерения...

(2) весь нюанс - а зачем ВТ, если её нельзя использовать? Не универсальный механизм, призванный якобы ускорять выполнение запроса, да еще столько вокруг в самой платформе 1С накручено (а уж восхвалений в книжках - сотни страниц, причем об ограничениях - ни гу-гу), а применение - строго ограничено.

(3) вы регистр РН зачем вообще создаете? Измерения в нем хранить?

(4) Я сказал что нельзя? Можно.
А использовать хотя бы потому, что в некоторых случаях работает быстрее

Ну сделай регистратор измерением, если так уж приспичило. Кто мешает-то? Зачем косяк проектирования структуры какого-то конкретного регистра валить на платформу?

(6) ... только эти некоторые случаи ограничиваются очень сильно :)
И об этом нособо не распространяются в теории :)
(7) и что в результате получится в уж готовой типовой конфигурации, работающей несколько лет?

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

P.S. Ассоциация. В 1с нет операций ++ и --. Вывод: механизм арифметических операций реализован криво и должен быть удален.

(0)
Может Вам про индексы почитать, про оптимизатор ....
Попробуй подобрать вручную...

В конце концов измерения проведи...

Обсуждать нечего - только собственные непонятки

(8) Ты бы определился что тебя не устраивает: платформа или типовые?

(0) Нет варианта КГ/АМ

(0)
Почитай на досуге, как ты в ручном режиме будешь использовать эти таблицы
c разными вариантами отборов
>>
Размещение  данных  1С:Предприятия  8.1. Таблицы  и поля

Регистры накопления

Для каждого регистра накопления создается таблица движений (_AccumReg<n>) с полями:

   * _Period - момент времени движения;
   * _Recorder<suff> - ссылка на регистратор;
   * _LineNo - номер движения по данному регистратору;
   * _Active - признак того, что движение активно (участвует в подсчете остатков и оборотов);
   * _RecordKind - вид движения (приход/ расход);
   * _Fld<n><suff> - измерение, ресурс или реквизит (для каждого измерения, каждого ресурса и каждого реквизита);
   * _DimHash - хеш функция измерений. Поле присутствует, если количество измерений не позволяет организовать уникальный индекс по измерениям.

Если регистр поддерживает остатки, то создается таблица остатков (_AccumRegTotals<n>) с полями:

   * _Period - момент времени, на который посчитаны остатки;
   * _Fld<n><suff> - измерение или остаток по ресурсу (для каждого измерения и каждого ресурса).

Если регистр поддерживает обороты, то создается таблица оборотов (_AccumRegTurnovers<n>) с полями:

   * _Period - момент времени, на который посчитаны обороты;
   * _Fld<n><suff> - измерение или оборот по ресурсу (для каждого измерения и каждого ресурса).

Если регистр накопления участвует хотя бы в одном плане обмена, то создается таблица регистрации изменений (_AccumRegChangeRec<n>) с такими же полями, какие у таблицы регистрации изменений последовательности.

Если конфигурация содержит хотя бы один регистр накопления, то создается одна таблица настроек хранения итогов (_AccumRegOptions) с полями:

   * _RegID - идентификатор регистра накопления;
   * _Period - периодичность хранения итогов. Не используется;
   * _ActualPeriod - хранение актуальных итогов;
   * _Periodicity - периодичность регистра;
   * _RepetitionFactor - кратность. Не используется;
   * _UseTotals - использовать итоги;
   * _MinPeriod - минимальный период с которого надо пересчитывать итоги;
   * _UseSplitter - использовать разделитель итогов (для обеспечения параллельности проведения документов)

(13) да вот как-бы мне не нужны обороты по каждому реквизиту - а по регистратору в целом. Правильно, поэтому в итоговой виртуальной таблице нет поля _Fld<n><suff> по реквизиту. Это и не нужно.
Как писал Гений1С - нужно, чтобы был один вариант инструкции отбора, и если 1С "могет" - пусть все выбирает по "виртуальной таблице", а не может - накладывает условие "которое не может" уже после формирования ВТ (как ГДЕ).
И не пришлось бы огород городить с "обычными регистрами" и "виртуальными таблицами" - а был бы просто механизм запроса к регистру, быстро делающий отбор по измерениям (раз не смогли реализовать быстро по ссылочным объектам), и медленно - по всем остальным вариантам.
Кто из вас даст пример, когда нужно "медленно" получить данные по тем же измерениям РН, используя "обычный" метод доступа, и не нужно быстро - "с помощью ВТ"??

Вообще, странно - вся база в виде одной большой "таблицы" с ключами, а 1С не может быстро найти ссылки на ссылки.
Хотя - понятно: подробный механизм обработки СУБД SQL был отвергнут (мы умнее), а введен "как бы такой же или даже мощнеее" свой собственный - сначала преобразующий и обрабатывающий данные сам (1С-сервер), передающий их SQL, который сам тоже обрабатывает их по-своему(для хранения и быстрого доступа).
1С - не СУБД, и никогда ей не будет, вот и вся немощь 1С от этого.
А по логике - либо должна ей быть, либо д.б. полностью всю работу на ней строить.

Параметры ВТ работают на 100%
1) Если есть отбор по Измерениям - тогда норм.
2) Если есть отбор по Реквизитам Измерений - юзаем ВременныеТаблицы из Пакетных запросов.

(16) Или тут Холивор только по поводу Регистратора из Оборотного регистра?

(14) Это уже претензии к синтаксису языка запросов пошли?
(15) Трехзвенная архитектура лучше масштабируется. Не стоит охаивать то в чем слабо разбираешься.

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

(16) а вопрос "как получить отбор по реквизиту с использованием ВТ" попадает под холивар?
И можно пример, как использовать временные таблицы в отборе ВТ? Учтите, что отбор НЕ ПО измерению (по реквизиту измерения я запрос-отбор и так напишу в параметрах ВТ, без всяких врем.таблиц), а по регистратору.

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

Это как так?! :)
Мне нужна выборка из регистра, тут документ постольку поскольку является регистратором :)

(22) Ты может определишься все-таки что тебе надо? Только те записи, которые принадлежат определенным регистраторам или что-то другое? Если тебе нужен именно ОТБОР, тогда выбирай из таблицы движений.

(23) да, определенным регистраторам, - плюс отбор еще по реквизиту регистратора, например. Причем тут движения? Строки движений я и так найду, по регистратору.

(24)
ВЫБРАТЬ
   Продажи.Регистратор,
   СУММА(Продажи.Стоимость) КАК Стоимость
ИЗ
   РегистрНакопления.Продажи КАК Продажи
ГДЕ
   Продажи.Регистратор.Контрагент.Адрес = &Адрес

СГРУППИРОВАТЬ ПО
   Продажи.Регистратор

Этим вопрос исчерпывается.

(0) если честно предмет вопроса мне непонятен. Я бы лучше поставил вопрос, а почему еще нет параметра СОЕДИНЕНИЯ, и возможность ограничить выборку только одним ресурсом (если есть необходимость).

ГДЕ допустимо при очень больших объемах данных,
ВТ лучше использовать, чем обращения к основной таблице - в основную пишут документы,
Параметры ВТ можно использовать, если явно их указывать, без запросов в параметрах ВТ.

голосовалка ниочем

(25)регистр неправильно спроектирован.

(14) Лови гранату:

ВЫБРАТЬ
   Остатки.Номенклатура,
   Остатки.КоличествоОстаток,
   Резервы.КоличествоОстаток
ИЗ
   РегистрНакопления.ТоварыНаСкладах.Остатки КАК Остатки
   ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыВРезерверНаСкладах.Остатки КАК Резервы
       ПО Остатки.Номенклатура = Резервы.Номенклатура
ГДЕ
   Резервы.Склад В (&СписокСкладов)

Куда надо пеоместить условие?

Ибо так в разы быстрее. А если еще прикрутить умеючи временные таблицы , то ух как хорошо.

глупый вопрос теоретика, который сам ни разу не пробовал

(0) вот челу заняться то нечем

(29) 1C-cпециалист? Оно и видно.
Сказано же уже, что по ИЗМЕРЕНИЯМ можно отловить реквизиты, это и без вас уже я писал. И условие Резервы.Склад - при наличии такого реквизита у РН ТоварыНаСкладах, - поместится в РегистрНакопления.ТоварыВРезерверНаСкладах.Остатки (,,,Склад.АдресСклада В (&СписокСкладов)). И запрос там же поместится, и массив - был бы только измерением регистра отбираемый элемент.
А вот если он не входит в число "избранных" - все, только через ГДЕ.
И где в данном примере увеличение быстродействия и "юзание преимущества виртуальных таблиц", если все равно сначала отбор в ВТ идет всего и вся, причем два раза (и то даже не по регистратору, а по опять измерению), а потом обычный "медленный" отбор по Складу?

(27) "ГДЕ допустимо при очень больших объемах данных" - т.е. ВТ тут опять в пролете? Зачем тогда и высший смысл возни вокруг неё?
"ВТ лучше использовать, чем обращения к основной таблице - в основную пишут документы,
Параметры ВТ можно использовать, если явно их указывать, без запросов в параметрах ВТ." - не понял, расшифруйте :)
"В основной регистр пишут [записи, данные] документы.." а дальше выпали целые слова, стало совсем непонятно.
(28) А что такое "правильный" регистр? У вас регистры проектируются по одинаковые инструкции, а не по месту и назначению?
(26) А как вы видите в ВТ другие виды соединений!? И пожалуйста, берите одно измерение в отбор, и выбирайте по нему.

(30) вы повторяете за другими или как? вот хоть бы пример кто привел применения в отборе ВТ временных таблиц. Интересно взглянуть, что туда пихают :)

Итак, нечто, громко названное "механизм виртуальных таблиц", оказалось на деле просто сверткой по измерениям, и, как всегда, с добавками в виде одинэсовского взгляда на мир.
Ну так и сделали бы просто: месяц кончился - дополнительно вписывается в регистр строка итогов по числовым измерениям тут же, ставится особый ключ "ЭтоИтоги!!!" - и вуаля, выбирай по ключу итоги за месяц или как тебе надо. И никакого "особого механизма виртуальных таблиц", вообще никаких дополнительных таблиц на сервере.
И отбор можно было бы также по итоговым (+непопавшие до итога записи при "неитоговом" периоде выборки) только строкам делать.
Но нет, замутим этакое, чтобы выглядело как ВОООТ, а уж работать - ну как-нибудь.

(34)ВТ нужна для получения строго определенных наборов данных. Остатков, например.
"Пишут документы"- блокировки при записи данных.
В 1С правда почти везде "грязное" чтение, но особого утешения это не доставляет.
"Запросы в параметрах ВТ" - RTFM

"Правильный регистр" - структура таблицы, при которой не требуется разыменований, обращений через точку.

Такое впечатление, что структуру регистра разрабатывают одни, а запросы пишут другие. Вот уже когда придумываете регистр тогда и думайте, как сделать максимальное использование ВТ в будущих запросах. От одного индекса и плюсодного измерения база не попухнет.

(38) очень смешно.
Вы в 1С на каждую типовую конфу такое пишете? :)))
Типа, ребята, думайте, прежде чем мне такую поделку подсовывать?

(34) в (36) я вам описал, как получение тех же остатков можно было сделать нормальным способом.
У вас уже в RTFM появились "соединения в ВТ" или, все-таки, запросы в параметрах? Которые сами по себе отношения к ВТ не имеют, а только РАЗРЕШЕНЫ к использованию в ограниченном виде (как вложенный запрос во вложенный запрос)?
Про "правильный" регистр - это вам с Вуглускр1991 надо, может, вдвоем, пробьете 1С хоть в этом :)))

(36) >> Итак, нечто, громко названное "механизм виртуальных таблиц", оказалось на деле просто сверткой по измерениям

а мужики то не знают...

разберись до конца что такое виртуальные таблицы, глупые вопросы отпадут сами собой.

(41) глупая реализация - вызывает, по меньшей мере, недоуменные вопросы своим существованием. Вы сначала разберитесь, что такое "механизм виртуальных таблиц" по 1С, и что такое свертка регистра по ключевым полям.
И обсудите с мужиками. Где вы там обсуждаете. И тогда мужики тоже знать будут :)

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

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

Как в требованиях к спецу было сказано, так и использую

(43) ну конечно, грамотные люди держат в секрете тайны массонской ложи, не переставая оставаться грамотными людьми :))
Вот только грамоты, видно, не хватает, чтобы понять, что вопрос не "как написать запрос через ГДЕ", а как в данной конструкции использовать ВТ? А если нельзя - то почему этот механизм так распиарен, да еще и прославлен и начищент в книжках до блеска?

всё не читал. Но голос свой оставлю.

Так быстрее!

(45) присоединяйся к ложе :-)
в случае отбора по измерениям будет меньше кода в запросе, значит меньше ошибок, лучше оптимизация запроса,

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

Основное назначение ВТ  - быстрое получение остатков/оборотов по набору измерений за счет использования агрегатов. Сам по себе механизм виртуальных таблиц никакого быстродействия не несет. Обращение к данным ускоряется только за счет использования агрегатов.

Если нужно обратится к оборотам  РН с детализацией по регистратору, то  использование агрегатов без необходимости.  Даже более того, накладные расходы будут выше. Проще напрямую обратится к физической таблице регистра.

Если же по условиям задачи необходимо получать обороты в разрезе регистраторов.  Добавить новое измерение. В типовых именно так и сделано  - измерение "Документ продажи" в РН "Продажи". Хотя эффективность данного подхода сомнительна.

В общем случае для понимания сути и назначения механизмов было бы неплохо прочитать про структуру хранения данных в РН в книжке  "Профессиональная разработка в системе 1С:Предприятие 8" http://v8.1c.ru/metod/books/book.jsp?id=63.

Так же неплохо было бы глянуть  физическую структуру таблиц РН в SQL.  А если интересует физический механизм работы ВТ то с помощью профайлера разобрать план запроса и текст запроса в РН.

(45) А какие еще измерения в регистре Продажи? Нельзя найти всех контрагентов с нужным адресом, а в параметры виртуальной таблицы передать список контрагентов?

// Каждый механизм для своего, и для чего ВТ "распиарен" - он прекрасно справляется. Используйте вещи по своему назначению :)

(49) в том и дело, что измерения Контрагенты нет, есть только Регистратор (и то не измерение, а предопределенное поле). В параметры ВТ нельзя передать то, что не является измерением или его частью.
И отбор по контрагентам с нужным адресом вначале - это уже использование ГДЕ, а не ВТ :)

(48) "Основное назначение ВТ  - быстрое получение остатков/оборотов по набору измерений за счет использования агрегатов. Сам по себе механизм виртуальных таблиц никакого быстродействия не несет."
Так что помешало сделать так, как описано в (36)? И никаких поисков "по другим таблицам" и прочих "преимуществ" :). А также бы отпало желание пиарить ВТ вне свертки регистра по остаткам/оборотам.

"Добавить новое измерение. В типовых именно так и сделано  - измерение "Документ продажи" в РН "Продажи""
В УТ не нашел такого измерения. И "добавить новое" - это если на этапе разработки, а не когда уже база наработана, и "Продажи" так заполнен, что скоро под собственной тяжестью рухнет :(

(51)
"Так что помешало сделать так, как описано в (36)? "

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

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

"В УТ не нашел такого измерения" В какой версии?
Может там и измерения тоже  "Контрагент" нет?


Да и кстати запрос из (0) просто ужас как с точки зрения смого написния так и с точки зрения SQL. Не поленитесь - откройте профайлер и посмотрите что он из себя представляет.

(52) будете смеяться - но в в моей версии, в которой пишу, нет и поля Контрагент!
А теперь посмеюсь я - как, интересно, продажу в розницу вы запишете на контрагента? Интересно - на какого спишете? :))
Делать по кварталу (месяцу, году) в (36) - все также, как делает 1С сейчас: брать итоги за месяц, а потом, если период не совпадает, вычитать (прибавлять - как удобно) недостающие продажи. И все из этого же регистра, и никаких "доптаблиц, ускоряющих (засирающих базу) работу". И намного быстрее, чем за весь период считать "напрямую перебором"(именно за счет уже расчитанных итогов - только они в самой таблице уже будут; все - как в 1С, только умнее; и давно уже взято на вооружение путными системами СУБД). Или опять непоняли простой сути? :)
И насчет профилера - что я должен открыть в PostgreSQL?

(53) Контрагента нет, а адрес есть? Может все-таки от теоретических вопросов перейти к решаемой задаче? :)

(54) ну знаете, иногда заглядывает такой како-нить дядечка солидный, и говорит: "я вот буду у вас покупать 1 раз в месяц, но регулярно и партию в 5000 коробок. А вы мне скидочку какую-никакую, идет?" Вот он уже - контрагент :)

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

То есть вы его идентифицировать хотите по адресу? А если еще кто-то по такому же адресу купит? Я бы завела контрагента ИП "Солидный дядя - аноним". Кстати идея с отдельным регистром неплохая, раз в Продажах даже нет контрагента (кстати как тогда вы другим клиентам обсчитываете накопительные скидки?). Тут нам не только виртуальная, но и физическая таблица ничем не поможет. Кажется ВТ просто под раздачу попала :)

(0)Если у тебя есть сертификаты - то выкинь их и получи снова и так до полного просветления.

Пример быстродействия ВТ - совсем недавно немного поправил обработку от одного очень крупного франча - просто перенес условия из где в свойства виртуальной таблицы - время действия обработки уменьшилось с 1-2х часов до 5 минут

А за использования где тогда когда нужно использовать условия в свойствах ВТ руки бы отрывал...

(5*) еще один 1С-специалист? Ребят, вы хотя б профессионалами пытаетесь стать или так, куда повернут, туда и смотрим?

(61) Все еще не понял что такое ВТ и с чем едят ???
в (48) по-моему отлично все расписано

(62) здесь вопрос поднят несколько другой - зачем такое распиаренное средство передвижения, если оно ездит только в одном направлении и при попутном ветре.
ВТ - это свертка регистра по измерениям в оригинальном исполнении 1С.

(63) Нормально оно ездит. Приложи линейку к рукам.
(61) Ты так говоришь, как будто это что-то плохое.

(64) это жутко ограниченное средство, которое ПО УМОЛЧАНИЮ продвигается как универсальное средство получения данных из регистра.

(64) - да, я уже заметил, что прямые руки только у тех, кто дальше мануала ("Краткой истории партии") не ездит.

странно что нет до сих пор темы


"справочники vs документы"

или "регистр бухгалтерии vs регистр накопления"


вполне в духе этой темы....

(67) потому как 1С-ники и их описатели взяли на себя труд расписать назначения, различия, ограничения и способы использования как тех, так и других.

(68) ну не пользуйся 1С. Чего ты пристал? Ведь куча других программ есть. И никто тебя не заставляет пользоваться ВТ. Можешь не пользоваться. Как будто мы все собрались, приставили тебе нож к горлу и требуем пользоваться ВТ.

(66) "Пришла тушеночная невеста и нас всех разоблачила" © Даун-Хаус
Смотрю, (29) броню черепной коробки не одолело, но тем не менее:
Запрос №1:

ВЫБРАТЬ
   Номенклатура,
   Цена
ИЗ
   РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ТипЦен = &ТипЦен)
ГДЕ
   Цена >= &Цена

Запрос №2:

ВЫБРАТЬ
   Номенклатура,
   Цена
ИЗ
   РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ТипЦен = &ТипЦен И Цена >= &Цена)

Разницу крутому профессионалу объяснять надо?

Для небронированных, и потому открытых и незащищенных от выветривания:
в пятый раз повторяю - я кружу вокруг Регистра Накопления, и примеры - по нему же (которые так и не предоставили).
Что если просто выбрать из регистра, и тоже самое из ВирТ - будет быстрее, это даже Вам понятно.
А если попытаться выбрать то, что обычным способом выбирается из регистра, а по ВТ - 1С не предусмотрела - вот об этом тема.
Читайте (33) - там суть.

(71) "я кружу вокруг Регистра Накопления" - угу. Давайте для каждого чиха отдельные механизмы придумывать, так прикольно будет, прямо как в 7.7.
В (33) написано нечто, что не соотносится с сабжем никак, если что.

77 намного более "программибельна", чем 8-ка - хотя и там не без SQL-недостатков :)

(71) если вы вставите в ВТ регистратор, она естественно станет не быстрее, а медленнее чем обычная таблица, потому что по слову

Регистратор.Контрагент.Адрес

вы включаете в запрос соединение со всеми документами, которые могут быть регистратором этого регистра. То есть дополнительно 100 таблиц в запрос хотите засунуть.

(71) правильно, потому что это - 1С.
А вот если б они не изобретали велосипед и сделали в ВТ отбор как в SQL (по индексам и ключевым строкам) - то и тем бы не было таких...

(75) ну в 1С работают не такие придурки, как тебе хочется.

да уж, достаточно взглянуть на 8.2 и вспомниь историю версий: 6-7.7-8.0-8.2
И восхититься глубиной и провиденьем 1С в отношении своего собственного продукта.

Хотя чего говорить.... есть поклонники 1С, создатели которого даже не удосужились сделать безусловный переход GoTo...

(78) Жгешь.