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

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

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

Обращение к разным БД в одном запросе [D7, firebird]

olevacho_ © (2007-10-27 09:59:00)
Как можно в одном СКЛ запросе обратится к разным БД. Например вставить записи в таблицу из одной БД полученные из набора данных из таблицы другой базы? Это нужно реализовать на Firebird.

Sergey13 (2007-10-29 11:00:00) [1]
> [1] atruhin © (27.10.07 12:42)
> Никак.

> [8] atruhin © (29.10.07 10:55)
> На клиенте много вариантов.

Как понимать тебя? 8-)

atruhin (2007-10-29 10:55:00) [2]

> БДЕ допускает гетерогенные запросы.

Но делает то это на клиенте. На клиенте много вариантов.

Sergey13 (2007-10-29 08:39:00) [3]
> [0] olevacho_ © (27.10.07 09:59)

БДЕ допускает гетерогенные запросы.

PEAKTOP (2007-10-28 02:11:00) [4]
Напомню Вам вопрос:

> Как можно в одном СКЛ запросе обратится к разным БД. Например
> вставить записи в таблицу из одной БД полученные из набора
> данных из таблицы другой базы? Это нужно реализовать на
> Firebird.
>

Ответы с 1 по 4 можете считать стебом потому, что действительно никак.

То, что Вам требуется, называется задачей репликации (синхронизации данных двух БД), потребность в решении которой возникает, когда либо РСУБД (РаспределеннаяСУБД) и данные из филиалов сливаются в ЦентральнуюБазу, либо репликация обработанных данных ЦентральнойБазы в копию, которая находится у провайдера и к ней идет обращение из скриптов сайта.

Допустим, что вариант РСУБД. Структура базы по всем филиалам предприятия постоянная, но есть справочники (например "ТОВАРЫ" и "КЛИЕНТЫ"), которые пользователи на филиалах ведут самостоятельно и ЦентральнаяБаза в принципе не может знать, что туда вколотят.
1) Создается генератор сессии CREATE GENERATOR GEN_SESSION_ID.
2) Создается в ЦентральнойБазе таблица-клон подгружаемого (только список доменов без ограничений ссылочной целостности) справочника плюс один домен - SESSION_ID
3) В момент старта клиентское ПО получает идентификатор сессии.
----------------------------------------------------------
Подгрузка:
4) Все данные таблицы из подгружаемой базы сливаются в таблицу-клон ЦентральнойБазы с идентификатором сессии.
5) Вызывается хранимая процедура, которой передается идентификатор сессии, и которая определят вставлять/не вставлять данные в основной справочник (тут уже Ваша личная бизнес-логика). Эта же процедура может вести еще одну таблицу, которая хранит значения "погружен" или "не подгружен" элемент справочника ранее, и если подгружен, то с какого филиала.
6) После выполнения хранимая процедура чистит таблицу-клон от данных с нужным идентификатором сессии.

Все изложенное выше - как вариант решения задачи, который не претендует на роль истины в последней инстанции.

olevacho_ (2007-10-27 19:37:00) [5]

> Никак. Возможно будет в FB 3.0 т.е. примерно через годик.

А в Interbase можно?

PEAKTOP (2007-10-27 17:53:00) [6]
> Только еще кэш соединений с БД организовать в модуле UDF, учесть отличие супера от классика и т.д. :)))

Извините, батенька, но вопрос звучал как "можно ли организовать", а не "можно ли организовать, чтобы не через задницу" :))

atruhin (2007-10-27 16:21:00) [7]
> [2] PEAKTOP © (27.10.07 14:54)
> Ты не настоящий проктолог ! В селективном запросе - действительно
> никак. Но достучаться до другой базы из хранимой процедуры
> можно через UDF.

:))). Только еще кэш соединений с БД организовать в модуле UDF, учесть отличие супера от классика и т.д. :)))

Кстати в некоторых случаях можно использовать external table, т.е. с клиента на одном сервере, сформировал набор данных,
потом запросом с другого закачал.

PEAKTOP (2007-10-27 14:54:00) [8]
> Никак. Возможно будет в FB 3.0 т.е. примерно через годик.

Ты не настоящий проктолог ! В селективном запросе - действительно никак. Но достучаться до другой базы из хранимой процедуры можно через UDF.

atruhin (2007-10-27 12:42:00) [9]
Никак. Возможно будет в FB 3.0 т.е. примерно через годик.

Наверх

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