2015-03-23 2 views
2

Я создал схему звезд, чтобы хранить нагрузку данных социальных сетей и поставлять ее в приложение панели мониторинга с помощью 15 функций, которые вызываются с идентификатором пользователя и датой. Проблема в том, что каждая функция имеет в центре этого же запроса - выбор всей активности за указанный период времени. Затем запросы агрегируют данные и возвращают их для отображения на панели управления.Конструкция базы данных Postgres - функции панели инструментов

Например:

select 
    poster, 
    count(*) as volume 
from postgres.status 
where posted_date between in_date_from and in_date_to 
and timeline_id = in_timeline 
group by poster; 

и другой пример функции:

select 
    extract(dow from posted_date) as dayofweek, 
    count(*) as volume 
from postgres.status 
where posted_date between in_date_from and in_date_to 
and timeline_id = in_timeline 
group by extract(dow from posted_date); 

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

+1

проблема с X/Y. Почему у вас есть звездная схема? Зачем вам нужна * функция. (и: где функция?) – wildplasser

+0

Спасибо @wildplasser - я думаю, что я храню данные в большинстве логических форматов для требуемого типа отчетов, а функции отображаются как api для приложения для запроса с пользователями вход. Функции по существу, как указано выше, возвращают два столбца результата. – econnormist

+0

У вас есть звездная схема. Является ли это частью хранилища данных или вы можете рассматривать его как часть хранилища данных? –

ответ

1

Создайте временную таблицу для результатов вашего запроса и выберите ее содержимое в своих функциях.

BEGIN; 
CREATE TEMPORARY TABLE my_temp AS SELECT ... ON COMMIT DROP; -- Your query goes here. 
SELECT * FROM func_1(); 
SELECT * FROM func_2(); 
... 
COMMIT; 

Возможно, вам потребуется использовать EXECUTE, например. cursor variables в функциях с момента кэширования плана запроса для временной таблицы может вызвать проблемы:

CREATE FUNCTION func_1() RETURNS SETOF ... AS $$ -- Fill in your return type. 
    DECLARE 
     curs refcursor; 
    BEGIN 
     OPEN curs FOR EXECUTE 'SELECT * FROM my_temp'; -- Or the fields you need. 
     FOR row IN curs LOOP 
      ... 
      RETURN NEXT ...; 
     END LOOP; 
     RETURN; 
    END; 
$$ STABLE LANGUAGE plpgsql; 

Вы можете обработать ряд результатов по ряду в функции и возвращать одну строку за один раз с RETURN NEXT.

+0

Спасибо - будет ли это эффективной моделью для многих одновременных пользователей? Будет ли альтернатива использовать какое-то кеширование запросов - похожее на то, что доступно в MySQL? – econnormist

+0

Временные таблицы специфичны для сеанса, поэтому некоторые данные могут быть дублированы, но этого, вероятно, нельзя избежать, если содержимое панели мониторинга зависит от пользователя. (Я отредактировал свой ответ, чтобы база данных автоматически удаляла таблицу.) Существует хотя бы один кеш-запрос, https://code.google.com/p/pqc/, но я не использовал его. – tsnorri

+0

Спасибо, я закончил это с таблицами perm и таблицей «manager», содержащей параметры запроса (дата, временная шкала и т. Д.), А также имя созданной таблицы. – econnormist

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