7 марта 2011 г. 23:58 пользователь Dmitry E. Oboukhov
<unera@debian.org> написал:
DI> Смотря какая задача. Вашу, если честно, я до конца не понял.
ну попробую подробнее:
имеется родительская таблица:
| id | somecol |
и имеется множество таблиц от нее произведенных.
Фишка родительской таблицы в том что она неявно адресует всех дочек.
несмотря на то что все дочерние таблицы - разные, алогоритмика их
обработки примерно одинакова:
выбрали из них данное, обработали (запись ушла в другую БД), стерли
таким образом запрос вида
SELECT * FROM parent;
дает ответ на вопрос "есть ли данные для обработки в хотя бы одной из
дочерних таблиц?" а если сджойнить его с pg_class то и попутно ответ
на вопрос "в какой таблице есть данные для обработки?"
далее зная что в какой-то таблице есть данные мы имея имя этой таблицы
и уже заранее предвыбранный id записи можем забрать запись из этой
таблицы на выборку. а потом удалить.
вот и получалось две стадии:
1. селект по родительской
2. селект по одной из дочерних
я хотел это все впихнуть в хранимую процедуру, но полный аналог
двум селектам сделать не получается: либо запись с кучей безымянных
полей на выходе либо эти имена надо вручную расставлять, а это более
накладно нежели два общих SQL запроса в клиенте.
PS: дочерние таблицы - данные поступающие от различных устройств
измерения. Они актуальны только пока не обработаны, после обработки
становятся не нужны и удаляются.
Хороший пример задачи, где можно применить hstore.
Решение.
CREATE TABLE device(id serial not null primary key, name text not null); -- усройство
CREATE TABLE measurement(id serial not null primary key,
device integer not null references device(id),
mtime timestamp not null default now(),
data hstore not null) ; -- измерение
Итого: 2 сущности - "устройство" и "измерение". Никаких объединений с pg_class.
Проверка того, что есть данные для обработки:
select exists(select 1 from measurement);
Извлечение данных:
select dat from measurement;
Всё.
--
. ''`. 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
--
// Dmitriy.