Вход | Регистрация
 

Какой самый быстрый способ понять, что элемент справочника не менялся?

Какой самый быстрый способ понять, что элемент справочника не менялся?
Я
   Dmitry1c
 
03.03.21 - 07:15
От поставщика прилетает номенклатура и её свойства.
Свойства могут поменяться, номенклатура может быть новая/старая.

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

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

Может есть более удачные варианты?
   Paint_NET
 
1 - 03.03.21 - 07:21
Маркер изменений на стороне поставщика :)
А вообще да, только пореквизитное сравнение, если никаких признаков во входящем сообщении добавить нельзя.
   Галахад
 
2 - 03.03.21 - 07:22
Можно хранить к каждой номенклатуре некий хэш из получаемых от поставщика реквизитов. И сравнивать по нему.
   Dmitry1c
 
3 - 03.03.21 - 07:23
(2) о! это мб. будет быстрее
   RomaH
 
4 - 03.03.21 - 07:24
XDTO - получать два XML - разные - переписывать

хранить не надо, все-таки каждый раз считать
   Dmitry1c
 
5 - 03.03.21 - 07:25
(4) не понял
   RomaH
 
6 - 03.03.21 - 07:30
что надо - сравнить два объекта по определенному правилу - в нашем случае правило простое - каждый реквизит из некого набора должен быть равен

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

хранить ХЭШ - а нафига?
   Dmitry1c
 
7 - 03.03.21 - 07:32
(6) а сериализация не оч. прожорлива по ресурсам будет?
   Paint_NET
 
8 - 03.03.21 - 07:33
(2) О, интересное решение.
(6) При первом поступлении считаем хэш сообщения, сохраняем, при очередном поступлении считаем хэш полученного сообщения, сравниваем с сохранённым. Не сходится - значит, изменён. Элегантненько получается.
   RomaH
 
9 - 03.03.21 - 07:34
(7) - просто сложить строки в определенном порядке

Запрос

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

СтрокаСравнения  = Наименование + Код + ...
   Dmitry1c
 
10 - 03.03.21 - 07:35
(9) вот прямо душа лежит к варианту (2)
   Dmitry1c
 
11 - 03.03.21 - 07:36
По крайней мере если сделать вариантом (2), может быть быдлокодером не назовут ;)
   piter3
 
12 - 03.03.21 - 07:37
(7) а пересчитывать хэш при изменении операторами забыл, так что может выйти то на то
   RomaH
 
13 - 03.03.21 - 07:39
(8) - сколько будем хранить хэш первого? - история будет накапливаться по которой надо будет искать
(12) о, а я не заметил
хранение чем не удобно - поставщик изменить состав реквизитов - и хэш придется пересчитывать по новым правилам
   Paint_NET
 
14 - 03.03.21 - 07:40
(13) А зачем его хранить? Надо только с последним значением сравнивать.
   Paint_NET
 
15 - 03.03.21 - 07:41
(13) Ну, изменение состава реквизитов не только правила хэширования меняет, нужно и процедуры импорта модифицировать.
   RomaH
 
16 - 03.03.21 - 07:41
(14) я тебя понял как - приходит сообщение - мы не ищем номенклатуру (ключ) , а сравниваем с ранее записыными ХЭШами в БД (со всеми)
   piter3
 
17 - 03.03.21 - 07:44
Тут задачка как раз, что считать изменением, как мне кажется. Соответственно кто важнее, центр или обмен. Может проще конечно у автора
   RomaH
 
18 - 03.03.21 - 07:47
ща озадачу топикпастера - а удаление номенклатуры поставщиком как обрабатывать?
   Paint_NET
 
19 - 03.03.21 - 07:48
(16) С одним, последним хэшем. Т.е. нам надо проверить, изменилось ли что-то с _последнего_ раза.
   piter3
 
20 - 03.03.21 - 07:49
А так же дублем что считать. Как быть когда объединятся. Лучше сейчас задуматься, а как технически дело второе
   Dmitry1c
 
21 - 03.03.21 - 08:12
(18) здесь-то вроде все просто как раз.
   Dmitry1c
 
22 - 03.03.21 - 08:13
(20) а что значит объединятся?

две карточки в одну? ну останется один артикул, принадлежащий изначальной
второй - в утиль
   piter3
 
23 - 03.03.21 - 08:17
(22) что сравнивать будешь на изменение
   dmpl
 
24 - 03.03.21 - 08:24
(7) Меняется порядок реквизитов - и номенклатура уже разная получится.
   sdf
 
25 - 03.03.21 - 09:16
(2) +1

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

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

у меня есть исходная строка уже в json(или xml), от неё уже можно считать хэш
   sdf
 
27 - 03.03.21 - 09:29
(26) так да... Но а если в json(или xml) есть что-то лишнее. например дата/время формирования?
   Dmitry1c
 
28 - 03.03.21 - 09:44
(27) нету
   brainguard
 
29 - 03.03.21 - 10:09
(28) Тогда можно было бы просто исходную строку хранить. Хеш в данном случае просто позволяет ее сжать.
И это, SHA256 все же лучше. MD5 сломали
   Lama12
 
30 - 03.03.21 - 10:21
(26) А если порядок реквизитов изменится?
 
 Рекламное место пустует
   Кир Пластелинин
 
31 - 03.03.21 - 10:28
(30) собственно да. хэш-сумма в данном случае другая будет. но, с другой стороны, такая ситуация скорей исключение
   Михаил Козлов
 
32 - 03.03.21 - 11:22
Загнать данные поставщика в ТЗ и запросом получить расхождения не пробовали?


Список тем форума
Рекламное место пустует  Рекламное место пустует
Чтобы обнаруживать ошибки, программист должен иметь ум, которому доставляет удовольствие находить изъяны там, где, казалось, царят красота и совершенство.
Фредерик Брукс-младший
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.