14.01.2021, 12:00 | #11 |
Участник
|
Прежде всего, согласен с 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 и логах. будет работать только по запросу там еще куча соображений. но пока хватит. Последний раз редактировалось mazzy; 14.01.2021 в 12:07. |
|
|
За это сообщение автора поблагодарили: sukhanchik (10), vmoskalenko (4). |
Теги |
aif, ax2012, change tracking, интеграция, как правильно |
|
|