Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Поддержание синхронности БД [D6, Firebird]

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

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

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

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

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

Domkrat (2004-03-23 16:44:00) [4]
Тебе виднее когда ты будешь с ними синхронизироваться.

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

Fay (2004-03-23 16:43:00) [5]
Но отсылку-то они будут выполнять? Принимайте, и - вперёд.

}|{yk (2004-03-23 16:35:00) [6]
>"центр должен обеспечивать актуальность справочников".
Вот именно. Если у меня изменения в центре, то их нужно переслать на места. Но не делать же это при каждом изменении!

Fay (2004-03-23 14:22:00) [7]
Не нужно, т.к. "центр должен обеспечивать актуальность справочников".

}|{yk (2004-03-23 13:59:00) [8]
Но мне же нужно поддерживать актуальность справочников на местах! Вот основная загвоздка

Domkrat (2004-03-23 13:50:00) [9]
Или забирать данные с признаком 'новые' в филиалах.

bushmen (2004-03-23 13:48:00) [10]
В таблицах должны быть поля, которые однозначно определяли бы запись. А потом, как предлагали: export в файл, import. Если запись с этим кодом есть, то запись не импортировать.

Fay (2004-03-23 13:46:00) [11]
Проблема в том, какие данные выгружать. Сам-то знаешь?

Domkrat (2004-03-23 13:44:00) [12]
Камни:

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

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

}|{yk (2004-03-23 13:44:00) [13]
Центр - это не я. Для центра сделана уже система. Для мест нужно сделать ее вариант (упрощенный). На местах не нужна система планирования, которая используется в центре, и справочники из которой используются в моем модуле

}|{yk (2004-03-23 13:41:00) [14]
Проблема в том что это репликация между разнородными БД
проблема в том что данных таблиц(справочников) много.
Получается, что нужно заводить лог на все справочные таблицы
в центре, а потом пересылать на места. Возможно ли Oracle сохранять " моментальные снимки" таблиц справочников и делать потом анализ изменений, чтобы обойтись без лога?

Fay (2004-03-23 13:39:00) [15]
Вы ещё голубиную почту заведите. Можно на оленях возить.
Сложность не возрастёт, даже если везде поставить Oracle.
Лучше скажи, "центр" - это ты?

Наталия (2004-03-23 13:36:00) [16]
По-моему это называется словом "репликация". Есть много статей на эту тему. Пересказывать их здесь лень.

Плохиш (2004-03-23 13:34:00) [17]
>}|{yk © (23.03.04 13:30)

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

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »