iBase.ru Forum

Посоветуйте технически грамотное решение. Есть несколько БД на Firebird с идентичной структурой, которые лежат на разных ПК. Задача - написать на Delphi приложение "перенос данных", которое будет выполнять 1) экспорт данных из БД на FB в транспортный файл (один файл за один раз экспорта) и 2) импорт из транспортного файла того же формата в другую БД той же структуры. Короче говоря, данные должны копироваться так:

Firebird ---> MS Access ---> Firebird

Подробней... Раньше, когда БД на ноутбуках были на MS Access, а центральная БД была реализована на MS SQL Server, задача уже была реализована. В качестве транспортного формата использовалась БД на MS Access, то есть *.mdb, которые динамически создавались перед экспортом. Программа без труда выгружала данные при помощи гетерогенных запросов. Импорт из транспортного *.mdb выполнялся также посредством гетерогенных запросов. В общем все это работает, благодаря чудесного механизма гетерогенных запросов, делающих код приложения весьма компактным. Короче говоря, данные пока (гетерогенными запросами) копировались так:

MSSQL ---> MS Access ---> MSSQL (MS Access)

Теперь мы по ряду причин решили "слезть" с Microsoft, то есть портировать все наши прикладные БД с Access и MSSQL на Firebird. Тут я обнаружил, что любимых гетерогенных запросов в Firebird пока не реализовано. 2 дня искал по форумам, как люди решали аналогичные задачи. Узнал, что есть IBPump, какие-то утилиты командной строки, BDE с гетерогенными запросами, OLEDB провайдеры для Firebird... В конце концов можно и через TClientDataSet перекачивать по 1000 записей, но уж больно некрасиво это и муторно - читать-писать по одной записи там, где раньше можно было по много за один SQL-оператор.

1. В переносе (экспорт-импорт) участвует n таблиц. Экспорт - тупой. По вводу пользователя формируются WHERE-предложения, с помощью которых вырезаются нужные транспортнве наборы.

2. Импорт технически посложнее экспорта. Ведь экспорт идет в пустые таблицы. Чтобы при импорте решить проблему дублирования уникальных ключей, пришлость разбить импорт на 3 этапа - Загрузку (в пустые временные таблицы), Анализ (поиск и удаление дублей) и Фиксацию (INSERT в "резидентные таблицы" или "таблицы назначения").

3. В качестве формата транспортного файла хотелось бы оставить тот же MS Access, поскольку удобно, что один файл - не надо заморачиваться на папки, преобразование структуры.

Надеюсь на вашу помощь, друзья!

PS. Вообще-то задача, как мне кажется, должна быть весьма распространенной во всех тех областях, где данные могут собираться или вводиться на нескольких ПК, а затем должны копироваться-собираться в одну (или несколько) "центральную БД" на сервере. Не знаю как в Oracle, но вот в MS SQL Server'e вплоть до 2008 при всей его продвинутости до сих пор кроме шестеренок для такой задачи ничего нету...

В общем то решение мне кажеться зависит от количества баз, если их очень много можно реплику, но реплика подразумевает уникальные индексы для каждой базы, так как изменения могут производиться где угодно, если же изменения в центральной базе НЕ производяться то можно триггерами отлавливать изменения, писать их в лог таблицу, таким образом ты сможешь знать, что изменилось с момента последнего экспорта.
Простой пример:

Код: Выделить всё

CREATE TABLE LOGS (
    IND      BIGREPLIC DEFAULT 0 NOT NULL /* BIGREPLIC = BIGINT NOT NULL */,
    TABLEID  VARCHAR(15) DEFAULT 0 NOT NULL,
    FTYPE    CHAR(1) DEFAULT 'I' NOT NULL,
    FINDEX   BIGREPLIC /* BIGREPLIC = BIGINT NOT NULL */,
    FSTATE   SMALLINT DEFAULT 0 NOT NULL,
    DTIME    TIMESTAMP DEFAULT Current_TimeStamp NOT NULL,
    SQLS     BLOB SUB_TYPE 1 SEGMENT SIZE 4096 DEFAULT '' NOT NULL
);

здесь
TABLEID - имя таблицы
FTYPE - тип изменеия D,U,I - я думаю понятно
FINDEX - номер записи, первичный ключ
FSTATE - состояние 0 по умолчанию 1 - было экспортировано
SQLS - стало быть изменения для U='field1,field2,field3' и т.д. для I и D стало быть пусто

В принципе очень простое и надежное решение, к тому же в триггерах ты можешь условиями регулировать какие поля должны быть реплицированы при изменении а какие нет.
При такой структуре не надо проверять уникальность и т.д. не надо юзать MDB так как можно тупо писать SQL запросы в txt и тупо отуда их выполнять, НО ПРИ УСЛОВИИ что в центральной базе НЕ ДЕЛАЮТСЯ ИЗМЕНЕНИЯ.
Если в центральной базе так же делаються изменения то лучше бы обзавестить уникальными индексами, об этом уже много всего написано.

Обсуждение на SQL.ru.
http://www.sql.ru/forum/actualthread.aspx?tid=673299
Пусть там и идёт, незачем плодить топики.

На скруле NNTP отвалился. Так что я воспользуюсь случаем и тут пошлю аффтара на IBPhoenix Replicator. При правильной настройке эта старая собака может много трюков...

iBase.ru Forum

Экспорт и импорт через файлы

Экспорт и импорт через файлы

Re: Экспорт и импорт через файлы

Re: Экспорт и импорт через файлы

Re: Экспорт и импорт через файлы