Форум: "Базы";
Текущий архив: 2002.08.29;
Скачать: [xml.tar.bz2];
Вниз
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 придется расстаться. Если же в течение ближайшего года или полутора вы не собираетесь этого делать - забудьте об альтернативах, и продолжайте работать привычным способом.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2002.08.29;
Скачать: [xml.tar.bz2];
Память: 0.48 MB
Время: 0.016 c