【问题标题】:Creating trigger to move a row to an archive table创建触发器以将行移动到存档表
【发布时间】:2011-08-19 03:57:53
【问题描述】:

我是 PostgreSQL 中触发器的新手,我不知道我想做的是否是触发器工作,但这是我老师的建议。

我有以下链接表:

id | link | visited | filtered | broken | visiting

最后四个属性是布尔值,默认为 false。目前,我在 UPDATE 上将其设置为 true,并且不再使用它(行)。

新设计的思想是让链接表只具有idlink属性,其他属性为归档表(visitedLinksTable、brokenLinksTable、filteredLinksTable和visitingTable)。

触发器有用吗?他们说将它移动到另一个表(插入到某个存档表并从链接表中删除)

【问题讨论】:

    标签: sql postgresql triggers web-crawler


    【解决方案1】:

    这些方面的东西应该可以工作。细节将取决于您的特定架构等。

    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();
    

    【讨论】:

      【解决方案2】:

      触发器不会真正起作用。大概您需要某种方法来确定在删除链接时应该将链接移动到哪个表(已访问、已损坏、已过滤、正在访问),但无法告诉触发器链接应该去哪里。

      您可以使用几个非触发函数来封装这样的过程:

      • 链接进入链接表。
      • 将链接移至“访问”表。
      • 根据尝试链接的结果,将其从“visiting”移动到“visited”、“broken”或“filtered”表。

      您可以使用存储过程来处理每个转换,但我不知道您是否会比手动 INSERT ... SELECTDELETE 语句获得任何收益。

      但是,如果您真的对触发器有兴趣(嘿,谁不喜欢触发器?)那么您可以使用原始的六列表,添加最后访问的时间戳,并定期进行某种清理-上:

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

      然后您可以使用 DELETE 触发器根据布尔列将链接移动到您的存档表之一。

      【讨论】:

        【解决方案3】:

        我想你可以在最近的 PostgreSQL 上使用视图和视图触发器。一般来说,我认为最好还是将存储逻辑封装在数据逻辑中,而视图是一种有用的方法。

        另一种方法是通过函数访问/从表访问。这样,您可以在必要时更改存储逻辑的同时保持一致的 API。这是我通常使用的方法,但与视图方法相比,它有一些不同的权衡:

        1. 视图/触发器方法更适用于 ORM,而过程方法则完全不需要 ORM。
        2. 每种方法都会出现不同的维护问题。了解它们是管理它们的关键。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 2014-02-02
          • 1970-01-01
          • 2010-10-28
          • 1970-01-01
          • 2015-05-30
          • 1970-01-01
          • 2021-06-22
          相关资源
          最近更新 更多