Главный вопрос - "Когда это нужно"?
Если у вас не типовая конфигурация, а "почти типовая". 99,9% в ней есть какой-нибудь справочник, регистр сведений, план обмена или ещё какой либо объект метаданных, к которому идут постоянные обращения. Запустите замер производительности и посмотрите. С развитием конфигураций такие объекты возинкают.
К примеру у вас есть узлы обмена данными, в которые должны выгружаться изменения только их касающиеся, касаются их изменения или нет определяется исходя из реквизитов этих объектов. Код выполняется при записи каждого объекта в БД. КОнечно же их нужно кэшировать.
Или же ещё пример - у каждого пользователя в настройках задана организация/организации, к которым он имеет доступ, эти ограничения проверяются при открытии любой формы, а если используется RLS то даже страшно представить сколько раз они проверяются.
В этом случае каш будет выглядеть где-то так:
ПараметрыСеанса.РазрешенныеОрганизации = Новый ФиксированныйМассив(МассивРазрешеннхОрганизаций);Либо фиксированный массив (как в примере), либо соответствие, упакованное в хранилище значений. Кода вцелом не много, а прирост производительности может вас приятно удивить.
Но по логике вещей мы ведь знаем что если к таблице будут частые обращения SQL сервер просто закэширует её всю и будет доставать из памяти. Это верно. Но мы вспоминаем что таблицы не большие. (списко филиалов или сотрудников) и в данном случае основное время будет уходить на инициализацию сервером 1С соединения с сервером SQL, обращением к серверу, получением ответа, что занимает не так мало времени как кажется - на часто выполняющихся мелких запросах это особенно заметно.
необходимо зарегистрироваться для просмотра ссылки