2012-10-22 3 views
0

В настоящее время у меня есть 2 подключения ODBC на моем веб-сервере. Один, который подключается к нашей базе данных QAD нашего предприятия, а другой - к нашей пользовательской базе данных, используемой для расширения нашей базы данных. В этом примере с помощью paticular у меня есть записи сотрудников в базе данных QAD, а затем номер сотрудника в другой таблице в пользовательской базе данных.Cross Join Progress Database через OpenEdge ODBC и PHP

Есть ли способ установить перекрестное соединение между двумя соединениями odbc в php, так что мне не нужно пробивать результаты первого запроса и отправлять несколько запросов на основе полученных результатов для связывания мои записи вместе в php-массиве?

Лучшее, что мне удалось создать, - это построить предложение IN из моего первого запроса из нашей пользовательской базы данных, отправить второй запрос в базу данных QAD и затем слить массив в php. Однако это чрезвычайно медленный процесс по сравнению с обычным объединением SQL.

+0

OpenEdge, hunh? У меня веселое решение, но это только для JDBC (на OpenEdge 10+) и Ruby. Наверное, делает его неосуществимым для вашего сценария, но дайте мне знать, если нет. –

ответ

1

Не уверен, что вы уже нашли решение для этого, но есть статья Progress о том, как это сделать.

Quick Guide To Setting Up MultiDatabase ODBC Connectivity

У меня был подобное требование - Я хотел создать соединение между столом в первичной базе данных QAD и пользовательская таблицей в наших пользовательских базах данных. Я тестировал это, и он работает хорошо, хотя моя настройка немного отличается. Мне нужно было подключиться к QAD из Microsoft SSRS для создания отчетов против данных QAD - мне нужно было создать несколько отчетов, которые стандартный обработчик отчетов QAD не смог обработать.

Я тестировал это на Progress 10.1c (этот метод поддерживается только в 10.1b +).

Так шаги, которые я взял были:

  1. создать oesql.properties конфигурационный файл в соответствии со статьей, имеющей отношение к первичным и пользовательских баз данных.
  2. Создайте DSN системы ODBC на клиентской машине (в моем случае на компьютере под управлением Windows Server 2008 R2 с SQL Server 2008 R2 с SSRS) с дополнительными ссылками на базы данных в соответствии с этой статьей.
  3. Создайте связанный сервер в SQL Server с помощью ODBC DSN
  4. Создайте представление, которое использует синтаксис OpenQuery для извлечения данных из QAD (в моем случае это было создано в базе данных ReportServer) через связанный сервер.
  5. Создайте стандартный запрос T-SQL, используя представление в точке 3 в качестве источника данных. Это, в конечном счете, источник данных для моего отчета SSRS.

Я считаю важным, чтобы бит версии OS/Database и драйверы ODBC совпадали, но пока не подтвердили это.

В то время как мое требование отличается от вашего, в конечном счете, это конфигурация сервера QAD и настройка ODBC. Пока ваш PHP-клиент может выполнять аналогичную функцию с точки зрения команды OpenQuery, вы можете получить эту работу. У меня нет опыта работы с PHP, поэтому я не могу вам помочь.

Это кажется немного запутанным, но на самом деле работает очень хорошо и во многих случаях фактически превосходит запрос данных с использованием QAD-браузеров!

Надеюсь, это поможет.

Edit: Вот пример из команды OpenQuery - вы можете увидеть, что таблица присоединяется к работе в обычном режиме, но только требуют и дополнительная часть в справочной таблице.

CREATE VIEW [dbo].[vQADData] AS SELECT * FROM OPENQUERY(LinkedServerName, 
' 
SELECT custTable.item_date AS DESP_DATE, so_mstr.so_site AS SITE, so_mstr.so_po AS PO_NO, so_mstr.so_inv_nbr AS INV_NO, 
     ad_mstr.ad_name AS ADNAME, ad_mstr.ad_city AS ADCITY, ad_mstr.ad_state AS ADSTATE 
FROM customdbname.pub.customtable custTable 
INNER JOIN pub.so_mstr ON so_mstr.so_nbr = custTable.so_nbr 
INNER JOIN pub.ad_mstr ON ad_mstr.ad_addr = so_mstr.so_ship 
INNER JOIN pub.sod_det ON sod_det.sod_nbr = custTable.so_nbr 
WHERE so_mstr.so_site = ''SiteName'' AND so_mstr.so_shipvia = ''SHIPPER'' AND custTable.item_date IS NULL 
') 

Затем просто войдите в режим просмотра, используя обычный синтаксис SQL.

SELECT * FROM vQADData 
+0

Не совсем легкий ответ, на который я надеялся, но я думаю, что это так же хорошо, как я собираюсь найти. –

0

Краткая Ответ: Вы не можете JOIN таблицы между двумя соединениями.

Сценарии: (все в одном связи)

  • По умолчанию в большинстве баз данных, вы можете объединять таблицы в различных схемах предваряя имя схемы перед таблицей, как это:

(...) FROM defaultDB.TableA INNER JOIN extensionDB.TableA ON ({Condition}) (...)

  • в зависимости от вашей базы данных (Я не знаю о Progress DB глубоко), возможно, вы не сможете присоединиться к таблицам, принадлежащим схемам на разных серверах.

  • Объединение таблиц в разные базы данных (например: Progress x MySQL), это еще сложнее. Я слышал о Oracle Gateway, проприетарном решении, которое (не совсем уверенное) могло бы достичь этого последнего сценария.

В итоге:

Если ситуация не вписывается в первый сценарий (который указывает на наиболее очевидный подход), я думаю кратчайшее решение будет профилирование кода и оптимизации возможных узких мест , Адаптация вашего кода для parallel processing может быть более смелым.

+0

К сожалению, мне кажется, что мне нужны разные броузеры для разных баз данных, и я понимаю, что им нужно работать на разных портах, что заставляет меня использовать два отдельных ODBC. Если есть доказательства, в противном случае мне было бы очень интересно объединить оба odbc в один, чтобы выполнить это. –

1

Благодаря Tiran за его предложенное решение. Для тех людей, которые пытаются ссылаться на несколько таблиц через SQL-сервер, как это делал Тиран, у меня есть дополнительный вход.

Я пытаюсь вытащить данные из нескольких источников (Прогресс), одну и ту же структуру таблицы в одно и то же время и вставить их в наш хранилище данных (SQL Server). Поэтому я просто пытаюсь объединить несколько одинаковых структурированных таблиц в разных базах данных. Решение Tiran начало меня по тому же пути, но привязка баз данных Progress была громоздким процессом, который потребовал от меня найти DBA Progress с 2-3 днями свободного времени (его цитата), чтобы собрать это вместе. Когда я говорил с людьми в Прогрессе напрямую, они также указывали, что если я создаю представление с объединением на стороне Прогресса, он будет последовательно извлекать данные из каждого источника в представлении, а не одновременно. Однако это привело меня к еще одному открытию, которое похоже на то, что оно решит наши потребности и полностью пропустит работу со связыванием таблиц со стороной «Прогресс».

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

Source 1 - Table_A 
Source 2 - Table_A 
Source 3 - Table_A 
  • Создать подключение ODBC к источнику 1 имени Source1.
  • Создайте соединение ODBC с источником 2 с именем source2.
  • Создайте соединение ODBC с источником 3 с именем source3. (Обратите внимание, что вы, как правило, хотите установить настройку соединения на «Чтение незавершенных»).

В SQL Server создайте связанные серверные соединения с каждым источником.

ls_source1 
ls_source2 
ls_source3 

В базе данных SQL Server, что вам нужно ссылаться на базах данных Прогресса в, создать представление, соединяющее три различных соединения, связанный сервера вместе, используя соединение. Ссылки на связанные серверы будут нуждаться в использовании openquery. В этом примере с использованием select * из каждого связанного источника сервера предполагается, что все столбцы названы и структурированы одинаково для каждого источника.

CREATE VIEW table_name_v as 
SELECT * 
FROM 
(SELECT * 
FROM OPENQUERY(ls_source1, 
'select * 
from source1.dbo.Table_A 
') 
union 
SELECT * 
FROM OPENQUERY(ls_source2, 
'select * 
from source2.dbo.Table_A 
' 
union 
SELECT * 
FROM OPENQUERY(ls_source3, 
'select * 
from source3.dbo.Table_A 
' 
) 
) x 

С созданным представлением вы можете одновременно запросить все три таблицы в разных источниках Progress. Никакой дополнительной настройки на стороне Прогресса не требуется.

Существует важное предостережение, над которым я сейчас работаю. Если вы работаете на 64-битной машине с использованием 64-битного SQL Server, вам необходимо использовать 64-битный драйвер для подключения к базе данных Progress с параметром связанного сервера. Мои потребности требуют, чтобы у меня как 32-битные, так и 64-битные драйверы на одном компьютере, и у меня возникли проблемы с этим, поскольку, по-видимому, они не играют хорошо вместе, когда находятся на одной машине. Я смог установить как 64-битные, так и 32-битные драйверы на одном компьютере (был сайт с ошибкой в ​​Progress), который должен был отправить мне ссылку для этого драйвера, но я смог заставить кого-то туда направить меня в нужное место для получения 64-битного драйвера odbc. Средний человек не должен нуждаться в обоих драйверах и может просто использовать 64-разрядный. В качестве альтернативной работы, если я не смогу заставить обоих драйверов сосуществовать на одной машине, я нашел и подтвердил, что компания Connx предоставляет драйвер, обеспечивающий 64-битный/32-битный мост, который разрешает эту проблему для меня. В идеале, не требуется никакого программного обеспечения сторонних разработчиков.

Теперь, к сожалению, появилась новая проблема. связанные с сервером, которые я установил и использовали, более не работают должным образом. Два шага вперед, один шаг назад.

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

+0

Это хорошая информация. Мне любопытно, есть ли действительно большая производительность, делая это таким образом, просто подключаясь к прогрессу из приложения в 3 источника данных и делая свое соединение с самим приложением, но хорошо знать независимо. –

Смежные вопросы