IB6. Доступ к таблице в другой GDB.

← →
exciter_ (2002-08-07 15:34) [0]

Зачастую в книгах пишут, что работа с двумя алиасами не проблема. В принципе так и есть, Но. Как из хранимой процедуры в одном GDB работать с таблицами другой GDB? Борланд кричит что это возможно. Но в хэлпе об этом есть только запись в глоссарии "multi-access" вроде. Как быть? У меня финансы в одной GDB , а расшифровки в другой. Не знаю как соединиться прямо в процедуре к расшифровкам. Вот. Если у кого есть хоть наметки, пишите.

← →
3JIA9I CyKA (2002-08-07 15:47) [1]

А никак.

← →
elv (2002-08-07 16:20) [2]

>Как из хранимой процедуры в одном GDB работать с таблицами >другой GDB?
Никак без BDE.
>Борланд кричит что это возможно.
Ссылку пожалуйста.
>Как быть? У меня финансы в одной GDB , а расшифровки в другой.
Значит у тебя справочники в другой БД? Возможно неверно спроектирован проект.
>Не знаю как соединиться прямо в процедуре к расшифровкам. Вот. ?
Прямо никак. Так задумано. ;)
>Если у кого есть хоть наметки, пишите.
Как вариант можешь использовать UDF.

Но раз ты работаешь ч-з BDE, тогда читай ниже.
www.ibase.ru

Особенности BDE

или Архитектура BDE и его особенности при работе с SQL-серверами
...
Гетерогенные запросы
BDE обладает уникальной способностью выполнять запросы, которые обращаются к таблицам, находящимся на разных серверах баз данных (или к таблицам разных форматов). Это так называемые "гетерогенные" запросы. Иногда их называют "распределенными", т.к. данные "распределены" по разным базам данных возможно одного и того же SQL-сервера.

Выполнить гетерогенный запрос можно следующим образом:

1. открыть 2 или более TDatabase, каждый для соответствующей базы данных. Например, один компонент подсоединен как A к алиасу TEST, а другой, как
2. открыть TDatabase, который подсоединен к драйверу типа STANDARD(т.е. к локальным таблицам. Существование оных необязательно). См. окно свойств TDatabase.
3. выполнить запрос в компоненте TQuery, подсоединенном к "стандартному" TDatabase. В результате должна получиться такая "конструкция"

а запрос иметь вид

SELECT C.CLIENT_NAME
FROM ":A:CLIENTS" C, ":B:EMPLOYEE" E
WHERE E.EMP_NO = C.CLIENT_ID

Конечно, по смыслу это полная чушь, но зато показывает пример указания таблиц из разных базах данных. Еще один пример запроса можно найти по ключевой фразе "heterogeneous joins" в BDE32.HLP.

Пока я готовил и проверял этот пример, установка Query1.Active в true вызывала страшные содрогания винчестера. Дело в том, что подобные запросы выполняются следующим образом:

1. ядро Local SQL "разбирает" запрос, и выясняет, какие таблицы из каких баз данных используются в запросе
2. данные из каждой таблицы вытаскиваются в локальный кэш (т.е. на клиента), в память или временные таблицы.
3. извлеченные данные обрабатываются локальным SQL (join, where, order by и т.п.).

Однако происходит так не всегда. По крайней мере в моем тестовом случае Local SQL начал выполнять просто чудовищные операции:

Сначала для одной, а затем для другой таблицы был выполнен SELECT COUNT(*). Т.е. Local SQL сначала пытается понять, во что ему обойдется скачивание данных на клиентскую часть. Очевидно, записей в CLIENTS ему показалось мало, и он вытащил все записи из EMPLOYEE, а потом начал последовательно выбирать соответствующие записи из CLIENTS отдельными запросами для каждой записи (проверяя соответствие условия WHERE). Буквально SELECT ... FROM CLIENTS WHERE CLIENT_ID = ? ORDER BY CLIENT_ID ASC.
(зачем здесь нужен order by - неизвестно). Почему произошло не наоборот, т.е. меньшая таблица не была выбрана в память, неясно.

Можно даже не упоминать, что select count(*) на реальных данных может выполняться долго (даже без учета возможной сборки мусора). Не говоря о том, что в EMPLOYEE было 42 записи, и отдельных запросов к таблице CLIENTS получилось тоже 42.

Вот такая веселая арифметика. Зато получены четкие объяснения, почему "трещал" винчестер.

Однако, пусть даже и таким жутким способом, но BDE умеет выполнять гетерогенные запросы. Благодаря Local SQL и тому, что BDE умеет работать с локальными таблицами (которые он использует для хранения промежуточных данных таких запросов). Ни IBObjects, ни fibc/IBX, ни IB API не имеют таких возможностей, и соответственно, не могут выполнять гетерогенные запросы

Итог
После прочтения этой статьи может сложиться впечатление, что BDE вообще не пригоден для работы с SQL-серверами. На самом деле это не так. Если знать его архитектуру (надеюсь, статья вам в этом помогла), то можно снизить неэффективность BDE в приложениях до минимума.
Другой важный момент - скорость разработки. Она до сих пор остается самой высокой по сравнению с другими наборами компонент (даже с IBObjects). А скорость разработки - это в первую очередь более низкая стоимость разработки системы.
Кстати, может оказаться, что вся эта "неэффективность" в смысле большого объема передаваемых данных на вашей 100мбит сети и не проявится. А если сеть гигабитная, то вы вообще никакого лишнего трафика не заметите. И наоборот - для модемных соединений BDE, конечно, никуда не годится. Или если вам нужно тщательное планирование и управление транзакциями IB, то BDE здесь тоже делать нечего.

Есть и более жесткие критерии выбора - если вы собираетесь переходить на Kylix или IB6 (диалект 3), то c BDE придется расстаться. Если же в течение ближайшего года или полутора вы не собираетесь этого делать - забудьте об альтернативах, и продолжайте работать привычным способом.

IB6. Доступ к таблице в другой GDB. Найти похожие ветки