Профессия — 1С

рубрики: Виртуальные таблицы | Дата: 2 февраля, 2017

Как известно при чтении данных платформа 1С обращается к таблицам базы данных. Но для регистров платформа 1С на основе реальных таблиц умеет формировать виртуальные таблицы, которые физически в базе данных не храняться. Это позволяет разработчику вместо того, чтобы делать сложный запрос к реальной таблице, сразу получить данные из виртуальной простейшим запросом. А также исключает возможные ошибки. Поэтому использовать виртуальные таблицы нужно всегда, когда есть такая возможность. Особенно при сдаче экзамена 1С:Специалист. Рассмотрим разные типы регистров и посмотрим какие виртуальные таблицы предоставляет платформа для каждого типа регистров.

Регистры сведений

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

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

Для регистров накопления набор предоставляемых виртуальных таблиц также зависит от вида регистра. Как известно есть два вида регистров накопления: Остатки и Обороты

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

Доступны следующие виртуальные таблицы

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

Доступна только одна виртуальная таблица

Регистры расчета

Здесь также в зависимости от настроек доступны следующие виртуальные таблицы

В свою очередь есть три регистра расчета: Начисления, НачисленияДополнительные и Удержания. И регистры Начисления и НачисленияДополнительные включены в план видов расчета Начисления, а регистр Удержания соответственно в план видов расчета Удержания.

Так вот, для регистра расчета Удержания у нас тогда будут доступны две виртуальные таблицы с базой
БазаНачисления
БазаНачисленияДополнительные

Регистры бухгалтерии

Самым большим набором виртуальных таблиц обладают регистры бухгалтерии

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

Источник

Особенности работы с виртуальной таблицей данных графика регистра расчета

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

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

При получении виртуальных таблиц система старается действовать оптимально, в частности, выполняется только то количество соединений, которое необходимо для получения полей виртуальной таблицы перечисленных в разделе «ВЫБРАТЬ».

Следствием этого является то, что при составлении текста запроса не следует выбирать поля данной виртуальной таблицы «про запас». Эта рекомендация может показаться общей, но следует помнить, что, как правило, получение «ненужного» поля в запросе к реальным таблицам или другим виртуальным таблицам приводит к некоторому увеличению сетевого трафика и, в общем случае, весьма незначительному снижению производительности. Ясно, что получение в запросе пяти полей регистра мало чем отличается от получения в запросе еще одного, шестого поля, если речь не идет о «больших» полях. Но в случае виртуальной таблицы данных графика появление еще одного виртуального поля из ряда перечисленных выше изменяет ситуацию принципиально. Время выполнения запроса может измениться в разы. То есть рекомендация составлять запросы оптимально по части числа выбираемых полей принимает особый смысл для данной виртуальной таблицы.

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

Рассмотрим пример. В регистре сведений, назначенном в качестве графика, есть ресурсы «ЧислоДней» и «ЧислоЧасов». Рассмотрим три запроса.

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

Это связано с тем, что для получения полей «ЧислоДнейПериодРегистрации» и «ЧислоЧасовПериодРегистрации» выполняется одно соединение с регистром сведений по значению поля «ПериодРегистрации» регистра расчета (сколько бы ресурсов регистра при этом не пришлось суммировать). А при получении еще и поля «ЧислоЧасовПериодДействия», выполняется еще одно соединение с регистром сведений, которое выполняется по значению поля «ПериодДействия».

Источник

Виртуальные таблицы регистра бухгалтерии

Выборка из регистра бухгалтерии и работа с виртуальными таблицами мало чем отличается от выборки из регистра накопления. Поэтому перед чтением данной статьи рекомендую ознакомиться со статьей про работу с виртуальными таблица регистра накопления. В данной статье подробно будет рассмотрена только та функциональность, которая есть только у регистра бухгалтерии.

Выборка из регистра бухгалтерии

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

Выборка значений субконто:

Виртуальные таблицы регистра бухгалтерии

У регистра бухгалтерии немного больше виртуальных таблиц, чем у регистра накопления:

При этом у регистра бухгалтерии без поддержки корреспонденции не будет виртуальной таблицы ОборотыДтКт.

ДвиженияССубконто

Виртуальная таблица ДвиженияССубконто содержит в себе поля как основной таблицы регистра бухгалтерии, так и таблицы значений субконто:

Данная таблица получается соединением основной таблицы и таблицы значений субконто. Из всех виртуальных таблиц только данная таблица может содержать неактивные записи (поле Активность = Ложь), но при этом в самой таблице есть поле Активность, поэтому неактивные записи можно будет исключить в запросе.

Таблица ДвиженияССубконто имеет следующие параметры:

Данный запрос выберет первые 10 записей за период между &НачДата и &КонДата, с отбором по счету дебета = &СчетДт, выборка будет отсортирована по полю Организация.

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

Как правило данную таблицу используют для получения проводок вместе с субконто.

Виртуальная таблица остатки

Отличия от виртуальной таблицы регистра накопления

Виртуальная таблица остатков регистра бухгалтерии очень сильно похожа на виртуальную таблицу остатков регистра накопления, поэтому рассмотрим только основные отличия.

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

В нашем примере в настройках плана счетов было указано максимум два субконто, поэтому в таблице есть два поля для субконто: Субконто1 и Субконто2. Если на каком-то счете присутствует только одно субконто, то в поле Субконто2 будет NULL.

Во-вторых, для каждого ресурса создается по пять полей:

В поле Остаток будет остаток, как он хранится в таблице итогов. Дебетовый остаток будет больше нуля, кредитовый меньше.

Поля ОстатокДт и ОстатокКт рассчитываются по разному, в зависимости от вида счета:

В данном примере счете 41.01 активный, счет 60 — пассивный, а счета 76.01 и 76.02 — активно-пассивные.

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

Признак Балансовый у измерений и ресурсов никак не влияет на количество полей.

В-третьих, есть отличие при формировании виртуальной таблицы. Если в таблице итогов последние рассчитанные итоги были за июль 2021 года (то есть в таблице итогов есть запись с датой 01.07.2021 с остатком на конец июня и оборотом за июль), то при получении остатка на 20 июля для регистра накопления будет получен остаток из текущих итогов и по записям таблицы движений за период 20.07.2021 — 01.11.3999 будет досчитан остаток на 20 июля.

У регистра бухгалтерии в одной строке с остатком хранится оборот за текущий месяц, поэтому к остатку на конец июня будет прибавлен дебетовый оборот за июль, вычтен кредитовый оборот за июль, а потом от этого остатка по движениям за 20.07.2021 — 31.07.2021 будет досчитан остаток на 20 июля 2021.

В-четвертых, есть два новых параметра: УсловиеСчета и Субконто:

УсловиеСчета позволяет задать отбор по счетам учета, можно указать несколько счетов.

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

Источник

Регистры накопления. Виртуальные таблицы. Часть №1: Обороты

О регистрах накопления

В нескольких статьях представлены основные сведения о внутреннем устройстве регистров накопления, о SQL-запросах платформы при работе с ними и их изменение в зависимости от настроек регистра. Подробно описана работа платформы с разными типами регистров (остатков и накопления), а также принцип действия агрегатов.

Материалы созданы во времена платформы 8.2, поэтому некоторые моменты могут быть уже не актуальными, но основные принципы работы остались неизменными.

Больше года назад сайт был закрыт. Некоторые из его материалов будут реанимированы на Инфостарт.

Конкретно в этой статье речь идет о виртуальной таблице «Обороты» регистров накопления в базе данных. Все примеры из публикации Вы можете найти на GitHub.

Виртуальные таблицы

В статье «Регистры накопления. Структура хранения в базе данных» мы рассматривали таблицы, которые использует платформа для хранения движений в регистрах накопления, а также его итоговых оборотов или остатков в зависимости от вида регистра («Остатки» или «Обороты»). Также были подробно рассмотрены действия платформы с таблицами остатков и оборотов при записи движений в регистр.

Сегодня в статье проанализируем SQL-запросы, формируемые платформой, при обращении к виртуальным таблицам регистра. Напомню, что у регистров накопления существует всего три виртуальных таблицы:

Как мы видим, кроме физической таблицы движений, для которой в базе данных создается отдельная таблица, также имеются виртуальные таблицы. Всего их три:

Последние две становятся доступными только если вид регистра установлен как «Остатки».

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

Далее в статье проанализируем SQL-запросы платформы 1С:Предприятие 8.2 при обращении к виртуальной таблицам. При этом будем выполнять запросы при различных комбинациях параметров.

Сторона СУБД

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

Виртуальная таблица «Обороты»

Виртуальная таблица «Обороты» есть, как у регистра накопления с видом «Обороты», так и с видом «Остатки». Рассмотрим оба варианта. Начнем с последнего.

Вид регистра «Остатки»

Посмотрим состав полей таблицы оборотов на примере регистра «ОстаткиНоменклатуры».

В нем содержатся поля каждого из измерений, а также поля «Приход», «Расход» и «Оборот» для каждого из ресурсов в регистре. В нашем случае у нас два измерения («Номенклатура» и «Склад»), а также три поля «КоличествоПриход», «КоличествоРасход» и «КоличестоОборот».

В зависимости от установленного параметра «Периодичность» в состав доступных полей вирт. таблицы будут добавляться соответствующие периоды («ПериодДень», «ПериодМесяц» и т.д.).

Теперь напишем простой запрос для получения оборотов по номенклатуре за период. В параметрах виртуальной таблицы установим поля «НачалоПериода» и «КонецПериода», а в условия добавим отбор по складу «Склад №1». При выполнении запроса платформа сформирует два SQL-запроса к базе данных. Первый запрос получает настройки регистра накопления:

Используя эти настройки, платформа формирует SQL-запрос непосредственно на получение оборотов. Вот так выглядит SQL-запрос платформы для получения оборотов:

Старался подробно разобрать весь запрос. Если будут непонятные моменты, то прошу в комментарии. Исходный текст запроса на языке 1С:Предприятия выглядит следующим образом:

В случае, если для виртуальной таблицы также устанавливается параметр «Периодичность», например, в значение «Месяц», то SQL-запрос немного видоизменится:

Если в виртуальной таблице периодичность установлена «Авто», то в SQL-запросе будут содержаться поля периода для каждой из получаемой в запросе периодичности («День», «Месяц», «Год» и т.д.). Причина, по которой платформа хранит значения периода с увеличением части даты «Год» на 2000 лет мне не известна. Если кто из читателей подскажет, буду благодарен.

Мы с Вами рассмотрели SQL-запросы платформы при работе с виртуальной таблицей «Обороты» регистра накопления с видом «Остатки». Как мы видим, виртуальная таблица «Обороты» в этом случае берет данные из таблицы движений регистра. Даже, если обороты в запросе получаются за несколько месяцев, необходимые данные будут также формироваться по таблице движений без использования каких-либо сохраненных ранее итогов. И это понятно, регистр накопления с видом «Остатки» предназначен для учета остатков, а не оборотов. Далее мы увидим, почему для решения задач учета оборотов лучше использовать соответствующий вид регистра накопления.

Вид регистра «Обороты»

Виртуальная таблица «Обороты» включает в себя поля для каждого из измерений регистра, а также по одному полю на каждый ресурс. Для оборотного регистра «ДвиженияНоменклатуры» из тестовой конфигурации состав полей таблицы следующий:

Как и в предыдущем случае, в зависимости от параметра «Периодичность» в составе доступных полей появятся соответствующие периоды.

И так, выполним несколько запросов к таблице «Обороты» и проанализируем SQL-запросы платформы. Первый запрос на языке запросов платформы:

Первым делом платформа 1С:Предприятие получит настройки регистра накопления, к которому выполняется запрос. Запрос будет идентичный рассматриваемому ранее примеру, пойдем дальше. Сформированный платформой SQL-запрос тогда будет такой:

К комментариям в приведенном тексте добавлю, что вне зависимости от значений параметров «НачалоПериода» и «КонецПериода» запрос пытается получить данные и из итоговых таблиц, и из таблицы движений регистра.

Если в запросе на языке платформы мы добавим использование параметра «Периодичность» (например, поставим значение «Месяц»), то SQL-запрос платформы изменится аналогично рассмотренному примеру для регистра накопления с видом остатки. Будут добавлены поля выбранных периодов («ПериодДень», «ПериодМесяц» и т.д.) в секции запроса «SELECT» и «GROUP BY». Для нашего примера это месяц. Поля и группировки будут добавлены для всех вложенных запросов и, конечно, содержаться в результатирующей выборке. В нашем примере, выражения в поле запроса для получения периода будет таким:

Принцип получения значений периода был описан выше для регистра с видом «Обороты».

Заключение

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

По схеме видно, что наиболее оптимальным образом платформа работает с виртуальной таблицей «Обороты» для регистра накопления с видом «Обороты», поскольку использует рассчитанных итоги по оборотам в разрезе месяцев. И лишь в тех случаях, когда рассчитанных итогов для периода нет, тогда использует таблицу движений. Для регистра вида «Остатки» всегда используется таблица движений вне зависимости от настроек хранения итоговых записей. Именно поэтому следует внимательно отнестись к настройке вида регистра накопления при проектировании структуры метаданных конфигурации.

Интересен тот факт, что если для регистра накопления отключить использование итогов, то тогда запрос к виртуальной таблице «Остатки» станет невозможным. Будет появляться такая ошибка:

Причем, данная ошибка будет не смотря на то, что виртуальная таблица «Обороты» для регистра накопления с видом «Остатки» использует только таблицу движений.

Что дальше

В следующих статьях будет рассмотрена работа платформы с виртуальными таблицами «Остатки» и «Остатки и обороты». Также коснемся работы агрегатов регистра накопления.

Источник

Регистры сведений. За кулисами

На старт

Больше года назад сайт был закрыт. Некоторые из его материалов будут реанимированы на Инфостарт.

В нескольких статьях будут представлены основные сведения о внутреннем устройстве регистров сведений, о SQL-запросах платформы при работе с ними и их изменение в зависимости от настроек регистра. Рассмотрим некоторые особенности с выходом платформы 8.3 и совсем немного об оптимизации работы с ними.

Структура хранения

Поговорим о регистрах сведений. Но не о на настройках и их правильном использовании, а о скрытой от разработчиков стороне СУБД. Рассмотрим? как регистры сведений хранятся в базе данных.

Что там в базе

Структура таблиц, используемая для хранения данных и настроек регистра сведений, меняется в зависимости от настроек объекта метаданных в конфигураторе. Следующие настройки влияют на то, как будет платформ 1С:Предприятие 8.x хранить данные в базе:

Рассмотрим влияние этих настроек с простого примера. В тестовой базе у нас есть непериодический регистр сведений «Настройки»:

Единственное измерение «СтаутсТовара» ссылается на перечисление, все ресурсы имеют примитивные типы. Структура хранения такого регистра ограничивается только одной таблицей в базе данных:

Как видно из рисунка, структура хранения такого регистра достаточно примитивна. Каждому полю регистра в дереве метаданных конфигурации соответствует поле таблицы на стороне СУБД.

Рассмотрим еще один простой пример.

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

Кроме полей измерений и ресурсов в таблицу добавлено поле «Period», в котором хранится значение даты и времени записи. Вне зависимости от значения периодичности структура таблицы регистра не изменится. Если же обратно поменять периодичность в значение «Непериодический», то из структуры таблицы будет удалено поле «Period».

Если для регистра поставить настройку «Режим записи» в «Подчиненный регистратору», то в таблицу дополнительно добавится поле «RecorderRRef», в котором будет хранится ссылка на документ-регистратор, а также поле «LineNo» (Номер строки) и «Active» (Активность). Отдельно этот пример рассматривать не будем. Давайте лучше посмотрим на структуру периодического регистра сведений с включенной опцией хранения итогов среза последних:

Как раньше и было сказано, в таблице содержатся поля измерений и ресурсов регистра. Т.к. регистр подчинен регистратору, то в состав полей добавлено поле «RecorderRRef», в котором хранится ссылка на документ-регистратор. Периодичность у регистра установлена в «По позиции регистратора», но поле «Period» в таблице все равно осталось. При такой настройке в этом поле хранится дата и время документа.

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

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

Отдельно стоит упомянуть о таблице настроек хранения итогов регистра сведений. Для последнего примера эта таблица выглядит так (см. след. скриншот).

В таблице только одно поле, хранящее флаг включения итогов. Изменить эту настройку можно в режиме предприятия в управлении итогами:

Таблица настроек хранения итогов добавляется для регистра сведений, если значение периодичности регистра отличается от значения «Непериодический».

Рассмотрим пример формирования платформой таблиц итогов среза первых и среза последних.

Пример формирования таблиц итогов

Например, таблица движений регистра «Цены номенклатуры», который мы рассматривали в предыдущем примере, содержит следующие записи:

Тогда таблица итогов среза последних записей будет выглядеть так:

То есть в таблицу попали последние по периоду записи в разрезе измерений регистра. По такому же принципу формируется таблица итогов среза первых, только берутся самые первые записи в таблице движений:

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

Пойдем дальше

Мы рассмотрели варианты хранения регистров сведений на стороне СУБД в зависимости от их настроек, а также познакомились со служебными таблицами регистра для хранения итогов и настроек хранения итогов. Стоит отметить, что возможность хранения итогов для регистров сведений появилась только в версии 8.3.

Далее мы отловим SQL Profiler’ом запросы, которые формирует платформа 1С:Предприятие к СУБД при работе с регистрами сведений.

Запросы платформы

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

Непериодический регистр

В тестовой конфигурации у нас есть простой непериодический регистр «Настройки»:

Если мы сделаем запрос к таблице регистра с отбором по полю «УчитыватьВДокументахПоступления», то получаем простейший SQL-запрос:

В запросе выбираются поля регистра, а в секции WHERE устанавливается отбор по полю. Рассмотрим примеры с периодическим регистром.

Периодический регистр

Тестовая база содержит периодический регистр:

Как было сказано ранее, такие регистры могут иметь на стороне СУБД несколько таблиц:

SQL-запрос к основной таблице итогов ничем не будет отличаться от запроса к таблице непериодического регистра. Другое дело запрос для получения среза последних/первых записей периодического регистра. Вот так, например, выглядит SQL-запрос для получения среза последних записей без установки параметра «Период»:

Этот запрос используется платформой для получения среза последних записей. Принцип его работы прост: получаем макс. значение периода для записей в разрезе всех измерений, а дальше к этой таблице присоединяем записи из основной таблицы регистра. В результате мы получаем срез последних записей.

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

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

В версии 8.3 появились новые настройки, позволяющие избежать проблем с производительностью.

Особенности платформы 8.3

Версия 8.3 позволяет включить использование итогов среза первых и среза последних. Давайте рассмотрим какой запрос будет сформирован платформой для получения среза последних по итоговой таблице регистра сведений:

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

В примере, к подзапросу присоединяется левым соединением таблица справочника «Товары» для получения представления товара (Наименования).

Стоит заметить, что если срез последних получается в запросе без установки отбора по периоду (то есть текущий срез), то используется запрос выше. Если же поставить параметр «Период» для таблицы среза последних, то платформа будет использовать запрос аналогично запросы платформы 8.2. То есть таблица итогов не будет использоваться.

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

Свой запрос для среза последних

Написание собственного запроса для получения среза последних записей для 1С:Предприятия.

О чем идет речь

Ранее мы рассмотрели SQL-запросы, которые формирует платформа 1С:Предприятие при работе с регистрами сведений в зависимости от их настроек. Особый интерес вызывает запрос для получения среза первых / последних записей без использования таблицы итогов.

Как мы видим, в запросе используется соединение с подзапросом, что может стать причиной проблемы с производительностью из-за не оптимального плана запроса, который выберет оптимизатор СУБД. Это будет происходить не всегда, но 100% гарантии стабильности дать нельзя (подробнее о причинах неоптимальной работы с подзапросами будет идти речь в одной из следующих статей).

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

Пример запроса среза последних

Для получения среза последних записей напишем следующий запрос:

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

Если нужно поставить отбор, например, по товару, то запрос будет такой:

Отборы устанавливаются в той части запроса, где идет получение максимальных периодов по разрезам регистра сведений. Если мы посмотрим на SQL-запрос платформы в этом случае, то соединений с подзапросами мы не увидим:

1. Запрос получения макс. периодов

2. Получение значений ресурсов регистра для найденных периодов и измерений с использованием сформированной ранее временной таблицы

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

Срез первых записей

Попробуйте самостоятельно написать такой запрос и поэкспериментировать с результатом.

Финиш

На этом небольшая заметка по внутреннему устройству регистров сведений подошла к концу. За бортом осталось множество вопросов:

Официальная документация, публикация от Сергея Носкова и Ваши собственные эксперименты всегда помогут ответить на все возникшие вопросы.

Источник