Реализация репликации данных

[sergeypp]

Снова поднимаю давно избитую тему. Много было сказано о том надо или не надо ее использовать, а о том как ее использовать, какими методами ее реализовывать не особо. Тема конечно затрагивалась но не раскрывалась.. но это все вода.. теперь ближе к делу.
Была поставлена задача реплицировать набор справочников из головного офиса в дочерние. Есть обязательное условие: все справочники заводятся в Центральном офисе.
На текущий момент я вижу следующие проблемы при реализации репликации
1. RecID. Генерация «своих» RecID на подписчиках.
2. Невозможность синхронизации таблиц на публикаторе при использовании стандартной репликации MSSQL
3. При стандартной репликации MSSQL проблемы с восстановлением базы из архивной копии
4. Номерные серии на подписчике
5. Добавление новых полей в таблицы сводится к пересозданию всей репликации
6. Код фирмы ‘dat’.
7. При репликации MSSQL контроль первичных ключей (По умолчанию DataAreaID и RecId). Если RecID будет меняться на подписчике, то может быть дублирование записей
8. При использовании репликации MSSQL на таблицах создаются триггеры.

Теперь краткие пояснения
1. можно конечно извратиться и написать процедуру, но сколько будет подводных камней никто не знает
2. пока таблицы будут учавствовать в репликации изменить их скуль не даст, так же как и не даст поднять базу из бакапа (не дай бог). Если же каким то хитрожопым способом удастся таблицу синхронизировать, то слетят тригеры на таблице, которые навешивает репликация. Короче, если не ветрянка, то понос.
3. см. выше
4. тут проще и можно закрыть глаза, так как справочники заводятся на публикаторе.
5. точнее так. Желание добавить поле, требует пересоздания репликации (см. 2)
6. Везде по одной компании, коды будут одинаковы. пропускаем
7. Если первичный ключ включает поле RecId, а репликация использует этот ключ, то при изменении RecId на подписчике на RecId базы подписчика может дать и точно даст сбой. при инсерте - дублирование, при апдейте и удалении, ошибка о том, что невозможно найти запись
8. см пункт 2.

Вот что мы имеем в итоге. Я хочу предложить на растерзание следующую схему
1. Данные из Аксапты попадают в специальную базу
2 Эта база реплицируется на подписчик,
3. там эти данные переносятся в аксапту

Теперь о том как это должно происходить.

1. Можно повесить тригеры, которые будут обрабатывать изменения, но при первой же синхронизации, тригеры слетят и все пойдет прахом. А программисты очень любят про это забывать.. ладно если потом скажут. Поэтому нужно другое решение. Например джоб с хранимкой, которая ослеживает по ModifyTime и перекладывает записи. Но тут могут быть проблемы с удалением. Их нельзя будет отследить.
Возможен вариант, что бы аксапта сама отслеживала изменения, внутренним функционалом, а потом делала SQL инструкцию по вставке данных в другую базу в таблицу (Кстати так и работет репликация Коруса для Кристалла). Если подписчиков будет несколько то скорее всего для каждого подписчика нужно будет создавать свою запись (планируется хранить и передавать измененные данные а не полную копию таблицы) а то потом не поймешь кто забрал а кто нет и когда запись нужно удалять. В итоге мы положили изменившиеся данные из аксапты в отдельную базу

2. База переносится на подписчики, здесь можно использовать как и репликацию транзакциями , так и передачу данных с помощью DTS . как лучше пока не знаю, может вы скажите?? В итоге мы имеем данные на сервере подписчика.

3. Как закатывать данные в аксапту? можно хранимкой, но тут возникает проблема сгенерацией RecID. Можно написать пакет в аксапте, который будет с определенной периодикой закатывать запросы к соседней базе в SQL инструкции, обрабатывать полученные данные и вставлять их внутренними средствами. Данные "успешно" отреплицировались.
Немного запутанно, но все же наверное понятно..
У кого есть какие замечания и советы по поводу этой схемы, может кто то использует другую схему, поделитесь знаниями. Что я не учел, какие проблемы еще могут возникнуть и.....
... Давайте не будем обсуждать что распределенка это плохо, давайте обсуждать КАК ее сделать..