|
14.01.2021, 13:07 | #1 |
Участник
|
Цитата:
поэтому я уже написал: Цитата:
5.3.2. [опционально] сериализованные значений полей, которые вы выгружаете.
но тут снова возникает "выбор инженера": упростить хранилище за счет того, что будут передаваться некоторое количество избыточных команд, или не передавать ничего избыточного собственно эту часть я и вырезал из своих рассуждений: допустить повторную передачу данных или кодить точные алгоритмы... Цитата:
но это если кодить. Последний раз редактировалось mazzy; 14.01.2021 в 13:11. |
|
14.01.2021, 13:07 | #2 |
Участник
|
SysDatabaseLog - и есть тот самый shadow. И понятно, что нельзя логировать таблицы типа проводок. Речь же идет о справочнике. А тут сам бог велел логировать, чтобы потом разбираться: кто ввел неправильные данные.
И RecId имеется в виду для таблицы SysDatabaseLog. И никаких 6 миллионов записей не надо считывать каждый раз. В примере я показал, что 26 тысяч запросов к SysDatabaseLog очень быстро работают для выборки нужных данных из 74 миллионов записей в SysDatabaseLog. А у автора вообще достаточно написать 1 запрос к таблице к SysDatabaseLog Я специально показал такой неоптимизированный пример с 26 тысячами запросов, чтобы было видно, что таблица SysDatabaseLog быстрая.
__________________
Мои утилиты для Аксапты версий 3.0-2012: http://aceofdatabase.blogspot.com/ |
|
14.01.2021, 13:17 | #3 |
Участник
|
Но вообще-то я согласен, что именно для этих целей использовать SysDatabaseLog неудобно по той причине, что там неудобно ловить момент изменения именно нужного поля. Хотя вроде мой джоб работает, но как-то сравнивать между собой два контейнера некрасиво смотрится. Неклассически что-ли.
Но все-таки это работает, и довольно быстро.
__________________
Мои утилиты для Аксапты версий 3.0-2012: http://aceofdatabase.blogspot.com/ |
|
14.01.2021, 13:17 | #4 |
Участник
|
нет. в SysDatabaseLog добавляются записи при каждом чихе.
в shadow таблица добавляется максимум 1 запись для каждой записи справочника. Цитата:
но видели мы на практике эти справочники... и что туда пихают. особенно, если в справочнике появляется "выгрузка в другую систему" Цитата:
чтобы выгружать - нет. никто ж не запрещает и shadow сделать, и в SysDatabaseLog включить. речь идет о том, что не надо использовать SysDatabaseLog для задач где нужно только "последнее" состояние. Цитата:
Сообщение от Ace of Database
И RecId имеется в виду для таблицы SysDatabaseLog. И никаких 6 миллионов записей не надо считывать каждый раз. В примере я показал, что 26 тысяч запросов к SysDatabaseLog очень быстро работают для выборки нужных данных из 74 миллионов записей в SysDatabaseLog.
А у автора вообще достаточно написать 1 запрос к таблице к SysDatabaseLog Я специально показал такой неоптимизированный пример с 26 тысячами запросов, чтобы было видно, что таблица SysDatabaseLog быстрая. |
|
14.01.2021, 12:14 | #5 |
Боец
|
Буквально недавно была такая же задача. Как сделали:
1. Представляем себе, что CustTable+Addresses+Contacts и прочее прилепленное - это XML документ для выгрузки, где CustTable - верхняя запись 2. Каждый раз, когда изменяестя CustTable (либо любая из дочерних) мы формируем этот XML и выгружаем куда-то там во вне. Но при этом, мы храним последнюю выгруженную версию XML где-то в отдельной таблице. 3. Естетсвенно, каждый раз, когда мы хотим выгрузить XML, мы сравниваем его с последней выгруженной версией. Выгружаем только, если отличаются. 4. Важно, что непосредственно выгрузка делается в Batch на основании таблицы-очереди. Т.е. п.2,3 формируют очередь на выгрузку, когда whereas отдельный Batch расталкивает её. Это развяжет по транзакциям, обезопасив работу пользователей и SQL. 4.1 В таблице-очереди мы храним не сам XML, а ссылку на запись верхнюю запись, что изменилась,т.к. ввиду периодичности работы Batch, хранимый XML может потенциально устареть. Из некрасивого: ============= - триггеры придется повесить на все таблицы, изменения которых влечёт формирование нового XML - придется хранить последнюю версию XML (или его хэш) - нужно покодить Из красивого: =========== - Гантированно выгружаете только в том случае, когда изменились нужные для выгрузки поля - Никаких завязок на modifiedDate\SystemLog, что ведёт приямиков в АД - Будет работать в любой версии AX. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
14.01.2021, 12:55 | #6 |
Участник
|
раз уж все равно кодите сериализацию, то лучше хранить для сравнения какой-нибудь хэш с ограниченной длиной от xml.
тогда для хэша можно использовать обычный NVarChar, а не Memo xml можно хранить только для вывода сообщений человеку что именно изменилось. |
|
14.01.2021, 13:16 | #7 |
Боец
|
Цитата:
Сообщение от mazzy
Угу. добавить еще проверку на recVersion, чтобы не сравнивать длинные строки
|
|
14.01.2021, 13:19 | #8 |
Участник
|
Цитата:
именно, наизнанку. Цитата:
Сообщение от DSPIC
Можно, было бы, но много дочерних таблиц... А от них нужно прийти к верхенму CustTable. Т.е. ты получишь 500К изменившихся Addresses, из которых придется найти только 50 клиентов, подлежащих выгрузке. Ну такое: неоптимально и наизнанку. Тригерры всё-таки нужно вешать, а с ними и recVersion сравнивать бессмысленно, т.к. заведомо поменяется.
я тоже через такие рассуждения прошел |
|
14.01.2021, 13:33 | #9 |
Боец
|
Цитата:
Пример: Выгрузке подлежат клиенты, у которых CommissionSalesGroup.Export=Yes. Выгружать нужно в т.ч., если изменились их адреса. Итак, поменялся RecVersion у 10К адресов, в которые входят наши 5 клиентов для выгрузки.Ну, вдовесок там ещё контакты и прочая DirParty лабуда. Аж интересно мне.. |
|
14.01.2021, 13:19 | #10 |
Участник
|
Цитата:
Сообщение от DSPIC
Имеешь ввиду - убрать триггеры на update\insert и сканить таблицы на предмет изменившегося recVersion, а потом уже смотреть, изменились ли выгружаемые поля? Можно, было бы, но много дочерних таблиц... А от них нужно прийти к верхенму CustTable. Т.е. ты получишь 500К изменившихся Addresses, из которых придется найти только 50 клиентов, подлежащих выгрузке. Ну такое: неоптимально и наизнанку. Тригерры всё-таки нужно вешать, а с ними и recVersion сравнивать бессмысленно, т.к. заведомо поменяется.
__________________
Мои утилиты для Аксапты версий 3.0-2012: http://aceofdatabase.blogspot.com/ |
|
14.01.2021, 13:29 | #11 |
Участник
|
Цитата:
но раз уж дошло до дочерних таблиц. на дочерних таблицах так или иначе, но будут заданы constraints на FK (в аксапте такие валидации выполняются в validateWrite, задаются в reltation) т.е. чтобы внешняя система смогла принять данные, данные должны быть переданы в определенном порядке - сначала родитель, потом потомок. т.е. в коде не будет простой выборки всех измененных данных. придется делать более сложный алгоритм. особенно если есть отношения (id, parentId) в самой таблице. тогда надо будет не только таблицы сортировать, но и измененные записи внутри таблиц |
|
14.01.2021, 13:41 | #12 |
Боец
|
О, отличная мысль. Я так буду заказчикам писать, когда с эстимейтами мимо выйдет.
Цитата:
Сообщение от mazzy
на дочерних таблицах так или иначе, но будут заданы constraints на FK (в аксапте такие валидации выполняются в validateWrite, задаются в reltation)
т.е. чтобы внешняя система смогла принять данные, данные должны быть переданы в определенном порядке - сначала родитель, потом потомок. т.е. в коде не будет простой выборки всех измененных данных. придется делать более сложный алгоритм. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
14.01.2021, 12:17 | #13 |
Участник
|
Я так понимаю, что основная проблема у автора в том, что:
Может быть все-таки есть возможность как-то систематизировать то, кто что получает или это, действительно, непредсказуемо? Кстати, да, у mazzy прозвучала неплохая мысль про удаление. А как его реплицировать? Последний раз редактировалось Raven Melancholic; 14.01.2021 в 12:19. |
|
14.01.2021, 14:30 | #14 |
Участник
|
и давайте попробуем вернуться к исходному вопросу:
Выгрузка измененных клиентов во внешнюю систему начнем с того, что сама по себе выгрузка нафиг никому не нужна. нужна синхронизация нескольких взаимосвязанных систем. поскольку вопрос был про выгрузку, то скорее в вопросе можно рассматривать связи в топологии звезда причем для упрощения обсуждения можно считать, что вопрос относился к центральной системе в топологии звезда причем нужна синхронизация данных в этих связанных системах, а не одна только выгрузка. синхронизацию (выгрузку и загрузку) могут делать разные команды на разных языках и с разными представлениями. перед синхронизацией не стоит задача нахождения глобального минимума передаваемых данных. синхронизация может передавать данные и повторно. но чем меньше трафик, тем лучше. так, вот прежде всего, нужно понимать, что: 1. к выгрузке будет и парная операция - загрузка. 2. загрузка предполагает, что могут быть ограничения данных, которых нет в системе-источнике, но система источник должна учитывать эти ограничения 3. синхронизация справочников - рано или поздно все равно должна синхронизировать все данные справочников. нужно ли расставлять приоритеты и передавать записи в определенном порядке - вопрос конкретной реализации. но скорее всего порядок записей не важен - главное, чтобы все записи всех справочников рано или поздно были синхронизированы 4. однако с точки зрения бизнес логики порядок таблиц в выгрузке важен из-за constraints на принимающей системе 5. также с точки зрения бизнес логики важен порядок записей в таблицах, где реализован паттерн (id, parentid) из за constraints на принимающей системе 6. на принимающей стороне возможно реализованы каскадные удаления, которые система источник должна учитывать 7. на принимающей стороне возможны уникальные индексы, отличающиеся от уникальных индексов в системе источнике, поэтому некоторые insert/update могут не выполняться на принимающей стороне 8. и т.п. Последний раз редактировалось mazzy; 14.01.2021 в 14:38. |
|
|
За это сообщение автора поблагодарили: Vadik (1). |
14.01.2021, 14:37 | #15 |
Модератор
|
__________________
-ТСЯ или -ТЬСЯ ? |
|
14.01.2021, 14:58 | #16 |
Участник
|
Цитата:
Сообщение от mazzy
начнем с того, что сама по себе выгрузка нафиг никому не нужна.
нужна синхронизация нескольких взаимосвязанных систем. поскольку вопрос был про выгрузку, то скорее в вопросе можно рассматривать связи в топологии звезда причем для упрощения обсуждения можно считать, что вопрос относился к центральной системе в топологии звезда Но в принципе интерестно обсудить как это более оптимально сделать. На первый взгляд такой протокол довольно гибкий, т.е. при добавлении к примеру новых полей в синхронизацию или добавлении новых групп клиентов они могут просто получить данные за более больший интервал(т.е. нет отдельной операции перевыгрузить все) Последний раз редактировалось trud; 14.01.2021 в 15:05. |
|
14.01.2021, 15:28 | #17 |
Участник
|
Цитата:
технической и внутренней задачи "найти измененные" влияет на внешний протокол обмена. но если это все что вы согласовали в протоколе то и не меняйте согласованную часть... |
|
14.01.2021, 15:59 | #18 |
Участник
|
Найти ближайшее решение, которое, при наименьшей гениальности, будет работать
X++: select top 1 * from decision where IsActive = 1 order by GeniusLevel
__________________
Мои утилиты для Аксапты версий 3.0-2012: http://aceofdatabase.blogspot.com/ |
|
15.01.2021, 16:33 | #19 |
Модератор
|
Цитата:
https://youtu.be/XMWiN1mnw7c?t=234 Я не уверен что такая реализация взлетит. Для этого в общем случае надо хранить все изменения (в виде снэпшотов, или как-то еще) по достаточно крупной иерархической структуре (6М клиентов, 17М адресов плюс наверное столько же контактов и т.д.). Хранить и обновлять эту историю годами (так как мы не знаем как далеко назад во времени может потребоваться заглянуть) , и при этом искать по ней в несколько потоков десятками запросов в минуту ? Я бы не стал. Возможно, кастомное и спецализированное решение на X++ и заработает, но "просто, гибко, быстро" - тут наверное придется выбирать и даже не 2, а 1 из 3 Но если заработает, было бы интересно узнать что и как Цитата:
Но в принципе интерестно обсудить как это более оптимально сделать
__________________
-ТСЯ или -ТЬСЯ ? Последний раз редактировалось Vadik; 15.01.2021 в 16:52. |
|
15.01.2021, 17:39 | #20 |
Участник
|
Цитата:
хранить нужно поледнее отданное "состояние" в каждую систему-приемник. причем и "состояние" нужно только если передаются не все поля, как правило нужен только признак изменения данных - recVersion или хэш с фиксированной длиной. Цитата:
вроде исходный вопрос был "есть внешняя система, ей как-то надо передавать клиентов из АХ которые изменились за интервал времени." Цитата:
а в чем ты видишь проблему? |
|
Теги |
aif, ax2012, change tracking, интеграция, как правильно |
|
|