В базу загружается номенклатура поставщиков примерно 1 млн позиций, периодически происходит добавление (тут всё нормально работает)
4 раза в час происходит актуализирование остатков и цен от поставщиков.
Загрузка делается одним большим пакетом данных (все поставщики сразу в одном файле).
Сделал периодический реквизит с ресурсами: цена и наличие, при изменении чего либо реквизит обновляется.
Как правильнее (что бы быстрее работало) обнулить реквизиты у номенклатур которых уже нет у поставщиков в наличии?
Из того что приходит в голову: проверять каждую номенклатуру из базы на присутствие её в файле загрузки актуальных остатков (но какие то большие получатся временные переборы )

Периодический реквизит в восьмерке? Что курим?

(1) :)

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

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

(0) В Ресурс (если хочется совсем быстро - в Измерение) воткнуть реквизит "Удалено" типа Булево и не учитывать такие записи при работе.
Ночью регламентным удалять такие записи

а может поставщика напрячь сделать вебсервис и получать цены только тогда когда они нужны?

по аналогии с каталогами запчестей...

в сутки мы шерстим 6 лямов записей и делаем кучу работы, для того что-бы реально потребовались 20 тысяч ? не странно?

(7) тут понимаешь в чем проблема.. вот ты обработал 20 тыс, а оно суко - покупатель или что запросил раз в полгода - 20тыс+1 позицию, а ее ты не обработал. все. бизнес на грани катастрофы.

как покупатель запросил - идет запрос и онлайн обновление...

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

(1) И ты не кури

Тут где-то рядом Маня шарится...

(6)Зачем предлагать административные решения технического вопроса, когда ТС их не просит? Самолюбие играет? Любишь нагибать поставщиков?
(0)Загружай свой миллион цен во временную или физическую таблицу, а потом выполняй
select
номенклатура
from
регистр.срезПоследних()
left join временная_таблица
where
регистр.номенклатура is null
Этих товаров нет у поставщиков.

(0) >проверять каждую номенклатуру из базы на присутствие её в файле загрузки

Почему не наоборот? Как идентифицируется номенклатура в файле?

Хотя бы структуру регистра покажи

организовать работу через прямую запись чтение sql

(15) миллион записей не такой уж большой объем, чтобы с прямой записью заморачиваться. К тому же прямая запись нарушает лиц. соглашение

Зафиксируем для будущих холиваров: в 1С "большие данные" это 1 млн. строк.

(5) Саму запись лучше не удалять, т.к. для статистики и анализа может пригодиться (хотя конечно, я забегаю вперед)

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

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

(17) упустили момент времени! Для какой то задачи это не много, а для какой то это уже много будет при учете время.

(20) Повторю вопрос. Как идентифицируется номенклатура в файле?

(17) Не в 1с, а в мозгах некоторых 1сников

(17) не так, большой объем в 1с это ЕДИНОВРЕМЕННАЯ обработка миллиона строк... а сколько их в базе пофиг

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

Например он ищет макароны, зачем ему цены на гречку?

то есть алгоритм может быть примерно такой

запросили макароны, мы смотрим когда обновляли макароны, если прошло более 30 минут но менее суток ставим в план обновить макароны (а клиент ничего не ждет а работает с тем, что в базе), а робот в фоне запускается раз в 10 минут и видит - надо обновить макароны и делает это.
и в параллель ночью обновляем те товары которые прошлым днем не обновляли.

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

учитесь :)

(25) +
то есть тебе к обмену надо регистрировать не номенклатуру а отдельные группы (или отборы)

(12)ошибся. вот так надо
where
временная_таблица.номенклатура is null

первое измерение - код номенклатуры. дальше сортировка слиянием. сработает?

поселить эту таблицу и связанную с ней работу в отдельную СУБД? из 1с ковырять через "Внешний источник данных".