В регистре сведений КэшКартинок есть Измерение = Номенклатура, Ресурс = Картинка(Тип ХранилищеЗначений) и Реквизит = Счетчик.

Допустим в КэшКартинок лежит картинка размером 10 Мб.

Каждый раз при чтений этой картинки, я хочу увеличивать счетчик + 1.
Чтобы знать, сколько раз была прочитана эта картинка.

Это нужно для того, чтобы знать, какие картинки редко читают и можно их удалить из кэша, а какие часто и можно их там оставить навсегда.

Вопрос такой. Будет ли распухать база если я вызову 1000 раз вот такой код:

НоваяЗапись = РегистрыСведений.КэшКартинок .СоздатьМенеджерЗаписи();
НоваяЗапись.Номенклатура = ТекНоменклатура;
НоваяЗапись.Картинка = Новый ХранилищеЗначения(ТекКартинка 10 Мб);
НоваяЗапись.Счетик = СтароеЗначениеСчетчик + 1;
НоваяЗапись.Записать();

Где, ТекНоменклатура и ТекКартинка одни и те же.

Вам всего лишь нужно обновить запись, прочитав ее через набор

вызови один раз и поставь значение 1000 )))

(1) Согласен, через набор будет правильнее. А через набор не будет распухать?
(2) Шутку оценил. Но это будет вызвано многократно в течении дня разными пользователями.

имхо,
блок А)
1) счетчик статистики должен жить отдельно от данных по которым ведется статистика.
2) голые данные статистики не должны содержать никаких механизмов или агрегатов или сумматоров.
3) все циферки и графики можно посчитать позже, а raw-данные подчищать опосля расчёта.

имхо,
блок Б)
не надо кешировать в СУБД. надо кешировать в памяти.

(3) Да вроде не замечал такого. Несложно и проверить - обновить на тестовой 100500 записей и сравнить размеры

(4) Я не знаю как кэшировать в памяти мою задачу.
Пост навеян вот этим моим постом:
Отображение картинки с подвисанием, как решить?
Решения я там не нашел. Рекомендовали положить картинки локально и читать их сервером и передавать на клиент. Я так и сделал, но проблема осталась.

На данный момент.
Картинку буду получать картинку фоновым задание на сервере. Проблема передать её потом на клиента.
В данном случае ничего другого не придумал как через регистр сведений.

(5) Понял, спасибо, вроде логично. Но попробую в копии прогнать и посмотреть.

(0) "Будет ли распухать база если я вызову 1000 раз вот такой код: " - с какого перепугу?

(8) Ну как с какого, удаление из таблицы SQL не сразу происходит, она просто помечается и в дальнейшем удаляется регламентыми заданиями SQL.
А новая запись с +10 Мб добавляется. Разве не так?

(0) Отдельный РС.
(6) На сервере формируем ТабДоки, с пустыми картинками, в поле "Имя" картинки добавляем путь до файла на расшаренной папке, на Клиенте дозаполняем пустые картинки в табдоке картинками из файлов.

(10) Я как раз изначально и столкнулся с проблемой получения картинки вот таким методом:
Картинка = Новый Картинка(\\192.168.0.250\image\catalog\catalog\2021\c5\c5eeef43-8617-11eb-ab5b-1c1b0deed3a9_0.jpg)

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

(11) Жесткий диск разгоняется

А, не, это SSD

(13) Да проблему к сожалению не решил. Так и не могу понять в чем она. Думал это из-за сети, а когда переложил локально, то получил ту же проблему. Диски да SSD. Разные компьютеры, разные ОС, разные сети.

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

в 1сДокументообороте есть непериодический и независимый РС ПротоколРаботыСотрудников, по смыслу тебе подходит. в измерениях ДатаЗаписи, субъект кеширования\протоколирования и сотрудник, который юзал субъект. туда просто вкидываются данные по мере чтения\записи реальных данных. аналитику проводят позже, отчетами.

это кеш между файлом на диске и субд.

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

можно ещё третий уровень дорисовать - кеширование на диске конечного юзера.

(15) Благодарю

Протестировал запись в регистр через СоздатьМенеджерЗаписи и СоздатьНаборЗаписей.

Создал пустую базу с одним регистром сведений КэшКартинокНоменклатуры
Исходный размер базы MS SQL: 102 400 Кб
Записывал картинку в рс размером 6 750 Кб.

После записи в цикле 100 раз СоздатьМенеджерЗаписи
Размер базы: 326 656 Кб

После записи в цикле 100 раз СоздатьНаборЗаписей
Размер базы: 289 792 Кб

Подробно с кодом:
https://disk.yandex.ru/i/Fjp0pV79l9o8Jg

Результат огорчил. Ожидаем было, что СоздатьМенеджерЗаписи будет увеличивать размер базы. Но то, что СоздатьНаборЗаписей увеличивал размер базы, разочарован, при этом я перезаписывал только реквизит "Счетчик".
Вывод база будет распухать.

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

(17) это при условии, что у тебя ключ "Номенклатура" и ты перетирал одну запись 100 раз?
хм, учту на будущее

(17) тут дело не в "СоздатьМенеджерЗаписи и СоздатьНаборЗаписей", а в принципах работы СУБД.

(17) (19) я тоже не понял, почему разный размер базы при использовании "СоздатьМенеджерЗаписи и СоздатьНаборЗаписей"

(20)
а) при перезаписи одной строчки, субд всё равно добавляет новую строчку в таблицу и метит прошлую невалидной.
то есть размер будет расти неизбежно.
б) почему есть разница между МЗ и НЗ - https://its.1c.ru/db/metod8dev/content/2722/hdoc
"При этом менеджер записи использует для выполнения записи два набора записей, устанавливая им соответствующие значения отборов." ©

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

(18) Так как создал пустую базу для эксперимента, то Изменение "Номенклатура" это Строка(10), как видно на скрине пустая при этом.

(17) зачем во втором тесте выгружать и загружать набор?

(23) Да, можно было и не выгружать.

Для чистоты эксперимента переделал код:

//Первый раз записываем
    НоваяЗапись = РегистрыСведений.КэшКартинокНоменклатуры.СоздатьМенеджерЗаписи();
    НоваяЗапись.Номенклатура = Номенклатура;
    
    ХранилищеКартинки = Новый ХранилищеЗначения(Новый Картинка("C:\111.jpg"));
    
    НоваяЗапись.Картинка = ХранилищеКартинки;
    //НоваяЗапись.Счетчик = аа;
    НоваяЗапись.Записать(Истина);
    
    //Теперь перезаписываем набором
    Для аа = 1 По Длительность - 1 Цикл
        
        НаборЗаписей = РегистрыСведений.КэшКартинокНоменклатуры.СоздатьНаборЗаписей();
        //Так как одна запись, то без отбора
        НаборЗаписей.Прочитать();
        //ТаблицаНабора = НаборЗаписей.Выгрузить();
        
        НаборЗаписей[0].Счетчик = аа;
        
        //НаборЗаписей.Загрузить(ТаблицаНабора);
        НаборЗаписей.Записать();
        
        Сообщить(аа);
        
        
    КонецЦикла;

Результат:
testRC.mdf стал размером 283 648 Кб

(24) а автоприрост у базы какой установлен?

+(24) а точно увеличился в размере именно mdf (если автоприрост "игнорировать")? по идее должен распухнуть чутка ldf

(25) (26) Прирост поставил по 1 мб

https://disk.yandex.ru/i/4u0HeMSQd7Gdxg

(27) отсюда и увеличение размера mdf. а вот как sql рассчитывает - хватает ли ему места или нет - хз.

(21) п.а - это только для файловой базы? или для скульной тоже?

(29) Я на MS SQL делаю, как видно из примеров, база растет, значит новые строчки добавляются.