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

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

Какой самый быстрый способ понять, что элемент справочника не менялся?
Я
   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 или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.