Ситуация:

В различных организациях установлены копии одной той же СУБД. Базы данных у них свои. НО ИНОГДА есть необходимость переноса части данных из одной организации в другую.

Упрощенно это так: БД состоит из одной таблицы (TableMain) + несколько справочников (Table1...TableN). Никаких on-line способов связи между ними нет, обмен ведется через "дискетку" (CDR, Flash Drive, e-mail, ect.). Интересуют схемы возможной организации обмена данными. Видимо это должна быть стандартная процедура импорт/экспорт в некий собственный формат, когда пользователь БД-источника отмечает некие записи, которые он желает передать БД-приемнику и делает экспорт, а user на БД-приемнике делает импорт. Мне на ум сразу пришла ...

... Схема №1, а именно: при экспорте из БД, в какой-либо формат (напр. DBF) делается "выжимка" отмеченных к экспорту записей таблицы TableMain + для всех таблиц внешних ключей делаются также копии этих таблиц, содержащие записи используемые в TableMain. При импорте, мы вставляем в TableMain экспортируемые записи, а в справочники только те которых там нет.

Этот подход не работает АБСОЛЮТНО: Поскольку коды ключей справочников вводятся в организациях независимо друг от друга, то ключи XXX и ХХY могут означать один и тот же элемент справочника, а одинаковый код ключей может обозначать разные элементы справочника для источника и приемника данных.

СРАЗУ ОГОВОРЮСЬ: все эти организации принадлежат к разным ведомствам нашей большой страны, очень часто "не любят" друг друга, и ввести единый кодификатор для справочников НЕВОЗМОЖНО.


... Схема №2: Использовать в качестве кодов справочников суррогатные ключи, с гарантией уникальности для каждой организации. Экспорт происходит также, как в схеме №1. При импорте мы ищем совпадение не по коду справочника, а по содержимому остальных его полей. Такой подход гарантирует от подмены импортируемой записи справочника с ключем XXX на запись справочника, содержавшуюся в основной базе (с тем де кодом XXX, но с другим значением). НО тогда неизбежны появления дубликатов записей справочников в БД - приемнике.

В ообщем вопрос такой: я ничего умнее схемы №2 придумать не смог. Я думаю, что задачи такого рода водникали у многих. Если не трудно, поделитесь опытом, как их решать.

Andres 1Задача называется репликацией. 100% гарантии отсутствия дубликатов не даст ни одно решение.
Почитать на тему: сколько угодно

Хвалили, кажется, Sybase (т.к. сам не пользуюсь, то не помню, какой именно:) ) за хорошие встроенные механизмы репликации.

мда... А вот что в одной из самых толковых ссылок по теме:

http://replication.chat.ru/:
Проблема репликации (синхронизации данных) по нескольким источникам информации представляет собой довольно нетривиальную задачу с, весьма, неоднозначным решением. Как это ни странно, учитывая что подобные проблемы возникают довольно часто, но универсального решения такой задачи на текущий момент практически нет. Почти все готовые репликаторы данных работают с существенными ограничениями по структуре и способам накопления и изменения данных в таблицах базы данных.


Собственно, я это понял еще до создания топика. А все таки, будут еще комменты с конкретными решениями?

Я, видимо, из несерьезных :). Но если конкретизировать условия вопроса, то в принципе все уже рассказано:

1) Одна главная таблица, с приблизительно 9-ю справочниками (FK)
2) Нет (и быть не может) всеобщей стандартизации кодов для реплик БД
3) Необходимо обеспечить перенос некого подмножества записей из главной таблицы БД№1 в БД№2 с соответствующей модификацией справочников
4) Чем более автоматизированным будет этот перенос, тем лучше (например приведенная мной схема№2 подразумевает дальнейшую вычистку вручную дубликатов записей, что не очень желательно)

СУБД: Firebird, но я не уверен, насколько тема вопроса платформо - зависимая. Если еще не все серьёзные люди отдыхают на дачах - просьба откликнутся. На любые дополнительные вопросы по конкретно реализуемой системе готов ответить.

Спасибо, там есть исходники, буду разбираться.