创建触发器以将行移动到存档表
我是 PostgreSQL 触发器的新手,我不知道我想做的是否是触发器工作,但这是我老师的建议。
我有以下链接表:
id | link | visited | filtered | broken | visiting
最后四个属性是布尔值,默认为 false。目前,我在 UPDATE
上将其设置为 true,并且不再使用它(该行)。
新设计的思路是让链接表只包含id
和link
属性,而将其他属性归入归档表(visitedLinksTable、brokenLinksTable、filteredLinksTable和visitingTable)。
触发器实用程序是为此吗?他们说将其移动到另一个表(插入到某个存档表并从链接表中删除)
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)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
沿着这些思路的东西应该有效。详细信息将取决于您的具体架构等。
Something along these lines should work. The particulars will depend on your specific schema, etc.
触发器实际上对此不起作用。据推测,您需要某种方法来确定删除链接时应将链接移动到哪个表(已访问、已损坏、已过滤、正在访问),但无法告诉触发器该链接应移至何处。
您可以使用几个非触发函数来封装这样的过程:
您可以使用存储过程来处理每个转换,但我不知道您是否会比手动 INSERT ... SELECT 和 DELETE 语句获得任何好处。
但是,如果您确实喜欢触发器(嘿,谁不喜欢触发器?),那么您可以使用原始的六列表,添加上次访问的时间戳,并定期进行某种清理:
然后您可以使用 DELETE 触发器根据布尔列将链接移动到存档表之一。
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:
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
andDELETE
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:
Then you could use a DELETE trigger to move the link to one of your archive tables based on the boolean columns.
我想,您可以在最近的 PostgreSQL 上使用视图和视图触发器。一般来说,我认为最好将存储逻辑封装在数据逻辑中,而视图是实现此目的的一种有用方法。
另一种方法是通过函数来访问/从表中访问。这样您就可以保持一致的 API,同时根据需要更改存储逻辑。这是我通常使用的方法,但与视图方法相比,它有一些不同的权衡:
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: