Создание триггера для перемещения строки в архивную таблицу - PullRequest
Новая
       5

Создание триггера для перемещения строки в архивную таблицу

1 голос
/ 19 августа 2011

Я новичок в триггерах в PostgreSQL, и я не знаю, хочу ли я выполнять триггерную работу, но это предложение моего учителя.

У меня есть следующая таблица ссылок: 

id | link | visited | filtered | broken | visiting

Последние четыре атрибута являются логическими и по умолчанию имеют значение false.В настоящее время я устанавливаю значение true на UPDATE, и он больше не используется (строка).

Идея нового дизайна заключается в том, чтобы разрешить таблицу ссылок только с id и link Атрибуты и другие атрибуты архивных таблиц (visitLinksTable, brokenLinksTable, FilterLinksTable и visitTable).

Используется ли для этого триггер?Они сказали переместить его в другую таблицу (вставить в какую-нибудь архивную таблицу и удалить из таблицы ссылок)

Ответы [ 3 ]

1 голос
/ 19 августа 2011

Что-то в этом роде должно работать. Детали будут зависеть от вашей конкретной схемы и т. Д. 

CREATE FUNCTION update_function() RETURNS TRIGGER AS $$
BEGIN
    IF NEW.visited IS TRUE
        OR NEW.filtered IS TRUE
        OR NEW.broken IS TRUE
        OR new.visiting IS TRUE THEN
        INSERT INTO archive_table (id,link,visited,filtered,broken,visiting)
            VALUES NEW.id,NEW.link,NEW.visited,
                   NEW.filtered,NEW.broken,NEW.visiting;
        DELETE FROM table WHERE id=NEW.id;
        RETURN NULL;
    END IF;
    RETURN NEW
END
$$ LANGUAGE plpgsql;

CREATE TRIGGER update_trigger
    BEFORE UPDATE ON table
    FOR EACH ROW EXECUTE PROCEDURE
        update_function();
0 голосов
/ 29 сентября 2012

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

  1. Подход просмотра / запуска лучше работает с ORM, тогда как процедурный подход избавляет от необходимостиORM в целом.
  2. При каждом подходе возникают различные проблемы с обслуживанием.Знание о них является ключом к управлению ими.
0 голосов
/ 19 августа 2011

Триггер не будет работать для этого. Предположительно, вам понадобится какой-то способ определить, к какой таблице (посещенная, неработающая, отфильтрованная, посещающая) ссылка должна быть перемещена при ее удалении, но нет способа сообщить триггеру, куда должна перейти ссылка.

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

  • Ссылка переходит в таблицу ссылок.
  • Переместить ссылку на «посещающую» таблицу.
  • В зависимости от результата попытки ссылки, переместите ее из таблицы «посещение» в таблицы «посещение», «сломано» или «отфильтровано».

Вы можете использовать хранимую процедуру, чтобы позаботиться о каждом из переходов, но я не знаю, выиграете ли вы что-нибудь по сравнению с инструкциями INSERT ... SELECT и DELETE.

Однако, если у вас действительно есть что-то для триггеров (и, эй, кому не нравятся триггеры?), То вы можете использовать свою исходную таблицу из шести столбцов, добавить метку времени последнего доступа и периодически делать какие-то до: 

delete from link_table
where last_accessed < some_time
  and (visited = 't' or filtered = 't' or broken = 't')

Тогда вы могли бы использовать триггер DELETE для перемещения ссылки на одну из ваших архивных таблиц на основе логических столбцов.

...