我们应该使用一些值更新表'tab1'中的某些列（可以从不同的表'tab2'中获取）。现在'tab1'几乎每隔几秒就会插入一条新记录（来自不同系统的MQ）。 我们想要设计一个解决方案，一旦有新记录添加到'tab1'就会更新'tab1'。它不必在添加记录的同一时刻完成，但更新越快越好。我们正在考虑什么是最好的方法：
1）首先我们想到了tab1上的'before insert'触发器，所以我们可以更新记录 - 但是我们的架构师对该设计进行了审查，因为组织不允许使用数据库触发器（不要知道为什么，但这是一个限制，我们被要求与之生活在一起）
2）我们想到，我们将创建一个存储过程，它将对'tab1'中的记录执行更新。将在shell脚本的长时间循环中调用此存储过程。每次迭代后都会有一个暂停，比如3秒，然后下一个循环将启动，这将再次调用存储过程。所以这项工作将在上午12点到晚上11:59运行，然后每晚重新启动。
我的问题是 - 这是否只有数据库解决方案？任何其他解决方案也是受欢迎的，但设计的简单性将是一个巨大的优势。一位同事想知道是否存在“触发式”解决方案，它将在数据库本身内执行该工作 - 因此我们不必编写shell脚本。
任何指针都将受到赞赏！
答案 0 :(得分：1)
回答你的问题：
问：是否只有数据库解决方案？
不太可能，考虑到您的架构的所有限制。
问：欢迎任何其他解决方案
似乎您可能的解决方案是让您的应用程序处理通常由触发器或存储过程处理的内容。只需在一次交易中完成所有操作。
答案 1 :(得分：1)
触发器明显的解决方案。
DBMS_SCHEDULER 另一个明显的解决方案。
Continuous Query Notification 这将是一个“触发式”解决方案。它意味着在特定查询的结果不同时调用应用程序。但是您可以调用PL / SQL而不是应用程序，并且查询可能是一个简单的select * from tab1;，它将触发任何表更改。通常情况下，我希望建筑师能够看到这个解决方案并说“触发器会更简单”。
DBMS_JOBS 这是旧版本的DBMS_SCHEDULER，并不是很好。但它有所不同，也许它不会被捕获为未经授权的功能。
忽略建筑师问题不在于他不赞成使用触发器或工作; 可能是禁止这些技术的合法理由。问题是他拒绝了一个合理的想法，却没有明确说明为什么不允许这样做。如果他了解数据库，或关心你的项目，或者像专业人士那样行事，他就会说：“哦，我很抱歉，我知道这是典型的做法，但我们不允许这样做，因为X，Y，Z。“