Коллеги, добрый день

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

Основное требование - нужно готовое решение типа промежуточной виртуальной БД с ODBC интерфейсом. Рассматривал OpenLink Virtuoso Universal Server, но пока так и не понял, как эффективно сделать такой UNION. Добавлю, что имеется более 100 таблиц, в связи с чем руками писать SQL для каждой таблицы неразумно.

Уверен, что задача типовая, но на данный момент удобного решения не нашел. Буду рад любым комментариям и ссылкам. Спасибо.


Таблица A

ID Date
-------------
1 1/1/2014
2 2/1/2014
3 3/1/2014
5 8/1/2014


Таблица B

ID Date
------------
1 1/1/2014
2 9/1/2014
3 5/1/2014
4 1/2/2014


Результат объединения типа UNION таблиц A и B

Кот Матроскин, спасибо. Проблема в том, что имеются 100 таблиц с большим количеством столбцов и будет очень трудоемко для 100 таблиц делать такого рода запросы. Кроме того, такое решение будет очень медленным, так как 2 таблицы лежат на разных серверах, а доступ к ним осуществляется по только по ODBC.

mad_nazgul, спасибо, возьму на заметку. Но у меня только ODBC c OpenEdge Progress на другом конце.

Кот Матроскин А как Вы себе представляете НЕ "медленное" решение при таких ограничениях? Rак оно "внутри" должно работать, чтобы было быстро?

Кот Матроскин, например, так... Виртуальная БД делает одинаковые запросы к двум БД с указанием сортировки вывода по первичному ключу. Далее, на лету выполняется соединение по строкам с учетом приоритета таблиц. Так как датасеты отсортированы, то даже не надо будет выделять много памяти на стороне виртуального сервера для выполнения такой операции. Замечу, что сортировка по первичному ключу может работать достаточно быстро, особенно, если используется кластерный индекс "для" первичного ключа на стороне сервера.

Кот Матроскин, да, все так, но:

1. Имеется 100 таблиц, для которых надо создать 100 вьюшек (написать 100 запросов) и не ошибиться
2. Я хотел бы иметь возможность к виртуальной (объединенной) таблице применять фильтры, которые виртуальный сервер теоретически мог бы применить к однотипным подзапросам, что существенно бы повысило быстродействие.

Кот МатроскинДостаточно написать один генератор таких запросов, довольно примитивный (Добавление условий туда тоже можно встроить).

1. Надо пользователям предоставить виртуальную БД. Фильтры будут задавать пользователи.
2. Одна из баз может меняться буквально каждую минуту.
3. Мне хотелось бы обойтись готовыми решениями.

DirksDR, спасибо, репликация вполне может помочь. Только нет доступа к базам, есть только ODBC. Но я не буду усложнять задачу, поищу решение в этом направлении.

softwarer, базы данных лежат на разных серверах, так что не уверен, что получится использовать FULL OUTER JOIN. Также не уверен, что OpenEdge Progress поддерживает такой вид объединения столбцов. Это можно было бы реализовать в промежуточной виртуальной БД, но это приведет существенному ухудшению производительности. А в случае создания вьюх придется для каждого столбца вставлять IFNULL.

DirksDR, Пользователям нужны непременно вьюшки? Они программисты?

Пользователи - не программисты, в своем большинстве используют Access, который по ODBC получает данные. Проблема в том, что изначальная БД сейчас разделяется на две БД. Одна содержит исторические данные, другая - данные за последний год, но отчеты могут использовать данные за различные периоды. Файлов Access много, менять каждый нецелесообразно.

mad_nazgul, мне приходится работать с тем, что есть. К сожалению, я не занимаюсь закупками БД. В больших компаниях это сделать не так просто. Что касается создания отдельной БД и синхронизировать данные, то конечно это можно сделать, но трудозатратно, так как много данных и таблиц (300Gb). Надо делать полноценное хранилище данных, которое пока в разработке.

DirksDR, одна база используется ERP системой. Сейчас она сильно разрослась и требуется очистка. Исторические данные планируется вынести в отдельную БД. Я прояснил момент по поводу настройки реплики - в случае OpenEdge Progress, к сожалению, не получится настроить реплику из двух разных БД. Скорее всего придется вьюхи генерировать и создавать.