Поддержание синхронности БД

← →
}|{yk © (2004-03-23 13:30) [0]

Встала такая вот задача. В центральном офисе есть БД на Oracle. На местах оракл устанавливать нельзя (дорого будет, потому им нужна к-л локальная и/или бесплатная СУБД) Я остановился на FB 1.5 embedded
Связь между центром и филиалами только через почту, через fido (так объяснили). Потому web-интерфейс сделать нельзя. С мест данные будут передаваться в центр, а центр должен обеспечивать актуальность справочников.
Вопрос - как бы лучше организовать процесс синхронизации и какие подводные камни могут встретится? Никто такую задачу в условиях разнородных СУБД не решал?

← →
Плохиш (2004-03-23 13:34) [1]

>}|{yk © (23.03.04 13:30)

Программа на местах экспортирует в файл, Программа в центральном офисе импортирует из файла.
В каком пункте проблема?

← →
Наталия © (2004-03-23 13:36) [2]

По-моему это называется словом "репликация". Есть много статей на эту тему. Пересказывать их здесь лень.

← →
Fay © (2004-03-23 13:39) [3]

Вы ещё голубиную почту заведите. Можно на оленях возить.
Сложность не возрастёт, даже если везде поставить Oracle.
Лучше скажи, "центр" - это ты?

← →
}|{yk © (2004-03-23 13:41) [4]

Проблема в том что это репликация между разнородными БД
проблема в том что данных таблиц(справочников) много.
Получается, что нужно заводить лог на все справочные таблицы
в центре, а потом пересылать на места. Возможно ли Oracle сохранять " моментальные снимки" таблиц справочников и делать потом анализ изменений, чтобы обойтись без лога?

← →
}|{yk © (2004-03-23 13:44) [5]

Центр - это не я. Для центра сделана уже система. Для мест нужно сделать ее вариант (упрощенный). На местах не нужна система планирования, которая используется в центре, и справочники из которой используются в моем модуле

← →
Domkrat © (2004-03-23 13:44) [6]

Камни:

1. Редактирование справочных данных должно производиться в ценре.
2. Могут получаться накладки, если в разных филиалах редактировались одни и те-же данные.

То есть основное делают в центре, а в филиалах ограниченное кол. во операций.

← →
Fay © (2004-03-23 13:46) [7]

Проблема в том, какие данные выгружать. Сам-то знаешь?

← →
bushmen © (2004-03-23 13:48) [8]

В таблицах должны быть поля, которые однозначно определяли бы запись. А потом, как предлагали: export в файл, import. Если запись с этим кодом есть, то запись не импортировать.

← →
Domkrat © (2004-03-23 13:50) [9]

Или забирать данные с признаком "новые" в филиалах.

← →
}|{yk © (2004-03-23 13:59) [10]

Но мне же нужно поддерживать актуальность справочников на местах! Вот основная загвоздка

← →
Fay © (2004-03-23 14:22) [11]

Не нужно, т.к. "центр должен обеспечивать актуальность справочников".

← →
}|{yk © (2004-03-23 16:35) [12]

>"центр должен обеспечивать актуальность справочников".
Вот именно. Если у меня изменения в центре, то их нужно переслать на места. Но не делать же это при каждом изменении!

Но отсылку-то они будут выполнять? Принимайте, и - вперёд.

Тебе виднее когда ты будешь с ними синхронизироваться.

А что там в базе ? Задача как видно однозначно не решается.

2}|{yk © (23.03.04 16:35) [12]
Справочники много места вряд ли займут. Шли полностью. В филиале заливай во временную таблицу все и перекачивай в рабочую только те которых нет. Еще можно придумать флаг для тех записей которые однозначно есть уже у всех (для уменьшения размеров экспорта).
Но работать это все будет только при односторонней репликации.

← →
Sergey Masloff (2004-03-23 22:07) [16]

Sergey13 © (23.03.04 16:59) [15]
>Справочники много места вряд ли займут.
Спорное утверждение. В курсе что ГНИ собирается покрыть кодами (КЛАДР) не только населенные пункты и улицы но и детализировать до строений и SIC! отдельных квартир? Ну что во всей отчетности будет требоваться видимо привязка к кодам? У меня сейчас справочник населеных пунктов (который тиражируется) 180 тыс., справочник улиц (пока) не тиражирую...

В любом случае ты прав в том что при односторонней репликации проблем нет, при двусторонней - тема для многолетней работы, диссертаций и все равно автоматом работать не будет. Будут сидеть операторы и руками коллизии выявлять - максимум что удастся дать им более-менее удобный инструмент.

2Sergey Masloff (23.03.04 22:07) [16]
Тот же кладр, помнится, в дистрибтиве занимает 6 дискет =9м. Не так уж и много для одноразовой пересылки. Кроме того, такого рода справочники обновляются 1 раз в год.
Потом, я имел в виду "собственные" справочники и в пожатом виде они вряд ли все таки представляют серьезные объемы. Хотя соглашусь бывают случаи и бывают другие случаи. 8-)
Еще один момент - чем дальше - тем "серьезные объемы" занимают все меньше места. 8-)

Поддержание синхронности БД Найти похожие ветки