От поставщика прилетает номенклатура и её свойства.
Свойства могут поменяться, номенклатура может быть новая/старая.

Как максимально быстро с точки зрения производительности понять, что объект поменялся и его надо перезаписать?
Поставщик присылать только изменения не будет, нет возможности. Реализовывать нужно именно на стороне читателя.

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

Может есть более удачные варианты?

Маркер изменений на стороне поставщика :)
А вообще да, только пореквизитное сравнение, если никаких признаков во входящем сообщении добавить нельзя.

Можно хранить к каждой номенклатуре некий хэш из получаемых от поставщика реквизитов. И сравнивать по нему.

(2) о! это мб. будет быстрее

XDTO - получать два XML - разные - переписывать

хранить не надо, все-таки каждый раз считать

(4) не понял

что надо - сравнить два объекта по определенному правилу - в нашем случае правило простое - каждый реквизит из некого набора должен быть равен

можно просто сложить строки - это будет проще всего и быстрее, XDTO - тоже сложение строк, просто более напыщенное

хранить ХЭШ - а нафига?

(6) а сериализация не оч. прожорлива по ресурсам будет?

(2) О, интересное решение.
(6) При первом поступлении считаем хэш сообщения, сохраняем, при очередном поступлении считаем хэш полученного сообщения, сравниваем с сохранённым. Не сходится - значит, изменён. Элегантненько получается.

(7) - просто сложить строки в определенном порядке

Запрос

Выбрать
Наименование,
Код,

СтрокаСравнения  = Наименование + Код + ...

(9) вот прямо душа лежит к варианту (2)

По крайней мере если сделать вариантом (2), может быть быдлокодером не назовут ;)

(7) а пересчитывать хэш при изменении операторами забыл, так что может выйти то на то

(8) - сколько будем хранить хэш первого? - история будет накапливаться по которой надо будет искать
(12) о, а я не заметил
хранение чем не удобно - поставщик изменить состав реквизитов - и хэш придется пересчитывать по новым правилам

(13) А зачем его хранить? Надо только с последним значением сравнивать.

(13) Ну, изменение состава реквизитов не только правила хэширования меняет, нужно и процедуры импорта модифицировать.

(14) я тебя понял как - приходит сообщение - мы не ищем номенклатуру (ключ) , а сравниваем с ранее записыными ХЭШами в БД (со всеми)

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

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

(16) С одним, последним хэшем. Т.е. нам надо проверить, изменилось ли что-то с _последнего_ раза.

А так же дублем что считать. Как быть когда объединятся. Лучше сейчас задуматься, а как технически дело второе

(18) здесь-то вроде все просто как раз.

(20) а что значит объединятся?

две карточки в одну? ну останется один артикул, принадлежащий изначальной
второй - в утиль

(22) что сравнивать будешь на изменение

(7) Меняется порядок реквизитов - и номенклатура уже разная получится.

(2) +1

свойства в структуру и от неё:

Функция СформироватьХеш(Данные) Экспорт
    
    ДанныеСтрока = ОбщегоНазначения.ЗначениеВСтрокуXML(Данные);
            
    ХешированиеДанных = Новый ХешированиеДанных(ХешФункция.MD5);
    ХешированиеДанных.Добавить(ДанныеСтрока);
    
    Возврат СтрЗаменить(ХешированиеДанных.ХешСумма, " ", "");
    
КонецФункции

(25) сериализация - лишнее (для производительности)

у меня есть исходная строка уже в json(или xml), от неё уже можно считать хэш

(26) так да... Но а если в json(или xml) есть что-то лишнее. например дата/время формирования?

(27) нету

(28) Тогда можно было бы просто исходную строку хранить. Хеш в данном случае просто позволяет ее сжать.
И это, SHA256 все же лучше. MD5 сломали

(26) А если порядок реквизитов изменится?

(30) собственно да. хэш-сумма в данном случае другая будет. но, с другой стороны, такая ситуация скорей исключение

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