DI> Смотря какая задача. Вашу, если честно, я до конца не понял.
ну попробую подробнее:
имеется родительская таблица:
| id | somecol |
и имеется множество таблиц от нее произведенных.
Фишка родительской таблицы в том что она неявно адресует всех дочек.
несмотря на то что все дочерние таблицы - разные, алогоритмика их
обработки примерно одинакова:
выбрали из них данное, обработали (запись ушла в другую БД), стерли
таким образом запрос вида
SELECT * FROM parent;
дает ответ на вопрос "есть ли данные для обработки в хотя бы одной из
дочерних таблиц?" а если сджойнить его с pg_class то и попутно ответ
на вопрос "в какой таблице есть данные для обработки?"
далее зная что в какой-то таблице есть данные мы имея имя этой таблицы
и уже заранее предвыбранный id записи можем забрать запись из этой
таблицы на выборку. а потом удалить.
вот и получалось две стадии:
1. селект по родительской
2. селект по одной из дочерних
я хотел это все впихнуть в хранимую процедуру, но полный аналог
двум селектам сделать не получается: либо запись с кучей безымянных
полей на выходе либо эти имена надо вручную расставлять, а это более
накладно нежели два общих SQL запроса в клиенте.
PS: дочерние таблицы - данные поступающие от различных устройств
измерения. Они актуальны только пока не обработаны, после обработки
становятся не нужны и удаляются.
--
. ''`. Dmitry E. Oboukhov
: :’ : email: unera@debian.org jabber://UNera@uvw.ru
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537