Выгрузка измененных клиентов во внешнюю систему

[DSPIC]

Цитата:

Сообщение от mazzy

Прежде всего, согласен с Vadik, требование опрашивать 6M записей с частотой 1 раз в минуту - это какой-то перебор.
Но скорее всего, заказчик хотел иметь возможность опрашивать часто и опрашивать повторно некоторые разрезы (по группам, по условиям платежей, по наличию скидочной карточки и т.п.)
поэтому простим такую формулировку.

Критика предыдущих предложений

1.
Change Tracking - хорош.
Но слишком привязывает в MS SQL. В наше непростое время Great Again вендор-lock - это серьезный недостаток

2.
ModifiedDateTime, RecID и прочие неубывающие последовательности - в топку,
поскольку именно этот статус позволяет узнать что изменилось во всем справочнике, но не позволяет запросить измененные только в некоторых записях,
и вынуждает делаеть полные запросы по всем 6M записей
(а время еще и требует филигранной синхронизации времени на разных аосах/клиентах)

3.
перехватывать событие/триггера изменений и записывать логи - чревато DDOS системы
на расчетных полях типа себестоимости в складских проводках, алгоритм долбит обновлениями до посинения.
(особенно категорически не надо использовать SysDatabaseLog)

Что есть в стандартной Аксапте?
4.
в аксапте уже есть поле recVersion.
Ядро Аксапты использует это поле в рамках механизма оптимистической конкуренции в формах для того, чтобы узнать изменилась ли запись в других Аксаптах.

Это то, что нам нужно!

подход с recVersion придумал не майкрософт, но почитать об этом подходе можно здесь
https://docs.microsoft.com/ru-ru/sql...n-transact-sql

Кратко как поле RecVersion работает в аксапте:
1. RecVersion = 0 при создани записи
2. RecVersion = random(int) при любом обновлении записи (повторю: это делает ядро Аксапты, программировать это не надо)

Инвариант:
С огромной вероятностью recVersion после обновления будет отличаться от recVersion до обновления

(ах это "почти"... длинные рассуждения о почти уникальных GUID и о инженерном подходе "на практике работоспособно")

Что предлагается
5.

5.1. у вас есть справочник, состоящий из нескольких связанных таблиц (tab1, tab2 ... tabN)
5.2. у каждого справочника аксапта обслуживает служебное поле recVersion

5.3. Создайте shadow таблицу для вашего справочника tabShadow, в которой храните:
5.3.1. refRecVersion1, ... refRecVersionN - recVersion таблиц, которые вы выгрузили во внешнюю систему
5.3.2. [опционально] сериализованные значений полей, которые вы выгружаете. Важно, чтобы:
5.3.2.1. сериализованные значения можно было удобно сравнивать на равенство (изменились ли?)
5.3.2.2. сериализовать можно в аксаптовский container - тогда не надо будет программировать парсинг. Но конейнеры в MS SQL хранятся в (Memo)-полях. Со всеми вытекающими для производительности
5.3.3. FK к вашему справочнику, которые позволят однозначно связать shadow-запись и запись в справочнике (связь 0,1..0,1)

5.4. при каждой выгрузке обновляйте shadow-таблицу

5.5. shadow таблица позволит вам четко определить запросами 4 состояния:
5.5.1. есть запись в tab, нет записи в shadow - запись в справочнике создана, ни разу не выгружалась
5.5.2. есть запись в tab, есть запись в shadow, recVersion не совпадают - запись в справочнике изменилась, надо выгрузить
5.5.3. есть запись в tab, есть запись в shadow, recVersion совпадают - запись в справочнике не изменалась
5.5.4. ест записи в tab, есть запись в shadow - запись удалена, надо дать команду на удаление внешней системе

5.6. c shadow таблицей вы можете накладывать любые фильтры на справочник и получать измененные записи только среди отфильтрованных
5.7. shadow таблица не будет нагружать вашу систему паразитной нагрузкой в insert/update/delete и логах. будет работать только по запросу

там еще куча соображений.
но пока хватит.

Ну... почти. Только корректно будет сравнивать не RecVersion, который обновляется при изменении совершенно любого поля записи. Нас же интересует изменение только того, что подлежит выгрузке. Поэтому, правильнее было бы опираться на свой собственный аналог RecVersion, который привязан к выгружаемой информации, а не всем 100500 полям документа.