Creating trigger to move a row to an archive table - sql

Question

I'm new to triggers in PostgreSQL and I don't know if what I want to do is a trigger job, but was suggestion of my teacher.
I have the following link table:
id | link | visited | filtered | broken | visiting
The last four attributes are boolean and default to false. Currently I'm setting it to true on an UPDATE and there is no more use for it (the row).
The idea of new design is let the link table only with id and link attributes, and the others attributes to an archive tables (visitedLinksTable, brokenLinksTable, filteredLinksTable and visitingTable).
Is trigger util for this? They said to move it to another table (insert into some archive table and delete from the link table)

Answer 1

Something along these lines should work. The particulars will depend on your specific schema, etc.
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();

Answer 2

A trigger wouldn't really work for this. Presumably you'd need some way to determine which table (visited, broken, filtered, visiting) the link should be moved to when you delete it but there's no way to tell the trigger where the link should go.
You could use a couple non-trigger functions to encapsulate a process like this:
Link goes into the link table.
Move the link to the "visiting" table.
Depending on the result of trying the link, move it it from "visiting" to the "visited", "broken", or "filtered" tables.
You could use a stored procedure to take care of each of the transitions but I don't know if you'd gain anything over manual INSERT ... SELECT and DELETE statements.
However, if you really have a thing for triggers (and hey, who doesn't like triggers?) then you could use your original six column table, add a last-accessed timestamp, and periodically do some sort of clean-up:
delete from link_table
where last_accessed < some_time
and (visited = 't' or filtered = 't' or broken = 't')
Then you could use a DELETE trigger to move the link to one of your archive tables based on the boolean columns.

Answer 3

You could use views and view triggers on recent PostgreSQL, I suppose. In general, I think it is best to encapsulate your storage logic inside your data logic anyway, and views are a useful way to do this.
Another way would be to have access to/from the table be through a function instead. That way you can maintain a consistent API while changing storage logic as necessary. This is the approach I usually use, but it has a few different tradeoffs compared to the view approach:
The view/trigger approach works better with ORMs, while the procedural approach dispenses with the need for an ORM altogether.
There are different maintenance issues that arise with each approach. Being aware of them is key to managing them.