Из FireBird в PostgreSQL

← →
VitalikS (2006-07-20 04:18) [0]

Подскажите как правильнее сделать перенос данных из одной базы в другую.
Требуется перенести определенные данные с рабочего места оператора (операторов много, в разных местах города), у него данные храняться на FireBird, в базу данных на PostgreSQL которая для всех операторов одна и операторы могут одновременно начать передачу данных. Доступ к FireBird через BDE, а к PostgreSQL через ODBC (используются компоненты BDE).

Стоит ли использовать компонент BatchMove? Не будет ли проблем при одновременной передаче?

← →
VitalikS (2006-07-20 11:13) [1]

Или как можно по другому реализовать данную задачу, какие компоненты использовать?

← →
Desdechado © (2006-07-20 11:24) [2]

Многое зависит от того, что за данные. Если у кадого свои, то проблем при одновременной передаче быть не должно, каждый ведь в своей транзакции.
Если есть данные, которые могут пересекаться (например, суррогатные сгенерированнные ключи), то проблемы будут даже при поочередной передаче.
Если речь идет о синхронизации (часть данных в одну сторону, часть в другую), то проблем будет еще больше.
И не совсем понятно, как потом в полученной БД отделяются одни операторы от других. Вряд ли в структурах данных отдельных операторов есть эта зацепка, а в общей наверняка должна быть. Значит, структуры разные.
И BatchMove вряд ли тут покатит.

← →
Val (from Kiev) (2006-07-20 11:25) [3]

нужно бы почитать про репликацию, потом решить для себя как и что собираетесь переносить, потом спросить о том, что непонятно\не получается.

← →
VitalikS (2006-07-20 12:34) [4]

> Многое зависит от того, что за данные. Если у кадого свои,
> то проблем при одновременной передаче быть не должно

Смотря что понимать под словом "свои", они уникальны по нескольким полям, совпадения могут быть только если брать отдельные поля и сравнивать, а так строка уникальна.

> И не совсем понятно, как потом в полученной БД отделяются
> одни операторы от других.

Передается номер окна оператора на каждую запись (окон на одной точке до 7), программа должна выбирать данные сразу со всех окон (база одна, проблем с этим нет).

> Значит, структуры разные.

Абсолютно одинковые. Я просто незнаю как будет себя вести этот компонент при массовой передаче и довольно таки частой каждые 15 мин, а может и ещё чаще. Приемниек у компонента Table поэтому и возникают сомнения, а вдруг какие-то глюки выявятся. Данные важные л/с, суммы, фамилии, важно чтобы каждая запись передалась.

> нужно бы почитать про репликацию

Читал, FireBird не поддерживает репликацию. Может плохо читал....натолкните на статейку..

> решить для себя как и что собираетесь переносить

Знаю что, вот как раз вопрос КАК? Опыта в таких задачах нет, а данные важные.

← →
Desdechado © (2006-07-20 12:47) [5]

> Передается номер окна оператора на каждую запись
Т.е. разделение не по исходным базам, а по "окнам"? Ну, тогда проще.
Не забудь про управление транзакциями.

>> нужно бы почитать про репликацию
> Читал, FireBird не поддерживает репликацию.
Почитать о принципах, а не о репликации в FB.

А для FB можно поискать на ibase.ru
Что-топо этой теме я там видел.

← →
Val (from Kiev) (2006-07-20 15:02) [6]

под "как" я имел ввиду общие принципы - периодичность репликации, файлами/запросами, таблицами/выборками, что нужно контролировать при переносе и т.д.

← →
VitalikS (2006-07-21 01:52) [7]

> Не забудь про управление транзакциями.

А как управлять транзакциями? Что под этим понимается?

> А для FB можно поискать на ibase.ru
> Что-топо этой теме я там видел.

Там и читал, но что-то непомогло, попробую ещё раз.

> периодичность репликации

Пока каждые 15 мин, но время должно изменяться.

> , файлами/запросами, таблицами/выборками,

ну вот в этом у меня как раз и вопрос, как лучше?

> что нужно контролировать при переносе

Необходимо чтобы все данные дошли до PostgreSQL.

Вот ещё возник один вопрос:
В свойствах компонента BatchMove можно указать таблицу Paradox для ПРОБЛЕМНЫХ записей (насколько я понял те которые по тем или иным причинам не переданы на сервер будут занесены в таблицу), но если какая-то запись была не передана (например обрыв линии) то она заносится в эту таблицу и помечается как не переданная, а потом снова передается и доходит до сервера нормально, а вот будет ли она удалена из этой проблемной таблицы (ведь она уже отправленна) или эта таблица как log просто тупо заносит все коряво переданные данные.

← →
Desdechado © (2006-07-21 11:43) [8]

> периодичность репликации каждые 15 мин
Что-то очень подозрительно. Не проще ли писать напрямую в центральную БД?

> А как управлять транзакциями?
Так, чтоб точно знать, какие данные дошли до центральной БД, а какие нет.
Что такое транзакция, надеюсь, знаешь. Если нет - гугли.

← →
VitalikS (2006-07-24 00:53) [9]

> Что-то очень подозрительно. Не проще ли писать напрямую
> в центральную БД?

Программа с которой работает оператор написана не нами и работает она с FB (ну или с подобными серверами). Так что писать напрямую в центральную базу нет никакой необходимости, да и в эту базу будет скидывать только один вид услуг, а их у оператора много.

> Что такое транзакция, надеюсь, знаешь

Знаю.

Управлений транзакциями начинается с starttransaction, правильно я понимаю это понятие?

> Управлений транзакциями начинается с starttransaction, правильно
> я понимаю это понятие?

Это, как бы так сказать, утверждение частное. :)

← →
Step[B.M.] (2006-07-24 15:01) [11]

Короче так:

1. пишешь библиотеку UDF (для IBase) c функцией, которая подключается к базе PGSQL и свои входные параметры вставляет в таблицу PGSQL. Рекомендую использовать компоненты ZeosDBO. Если данные успешно "засунулись" в "слона" - то ф-ия возвращает "1".

2. вешаешь эту функцию на триггер BEFOR EINSERT в IBbase на таблицу, данные которой тебе нужно засунуть в "слона". если функция возвращает "0" значица вызываем в тирггере EXCEPTION.

Step[B.M.] (24.07.06 15:01) [11]
Вот этоточно слон получится. Ибо UDF предназначены для очень коротких операций, и уж никак в них не следует делать подключение к внешним БД и запись в них. Это порочный путь.
Представь, что пропала связь "окно- главная БД", тогда никто не сможет внести никаких данных, поскольку триггеры будут валисться на ошибку.

Из FireBird в PostgreSQL Найти похожие ветки