我需要创建一个触发器，该触发器采用平面事件源并将其转换为带有 start_time 和 end_time 的行。
有两个系统和一个作业可以将数据从一个传送到另一个：
________ _________
| | Job | Destiny |
| Source | -----> | |
|________| data |_Trigger_|
在 Destiny 中，有两个表：
____________________ ________________________
| | Trigger | |
| Flat event table | <--------- | Copy of source table |
|____________________| |________________________|
以下是来自源代码的示例：
| datetime | tagname | value |
1/1/13 07:00 tag 1
1/1/13 07:05 tag 0
1/1/13 10:07 tag 1
1/1/13 13:13 tag 0
我需要数据看起来像：
| id | start_time | end_time | duration | uptime | reason
event1 1/1/13 07:00 1/1/13 07:05 5 0 xxx
event2 1/1/13 10:07 1/1/13 13:13 76 182 yxy
到目前为止，我已经创建了查找最后一个事件并对其进行更新的逻辑，它一直运行良好，除了一个小细节：如果事件发生非常频繁，系统将创建大量插入，并且该批量正在以奇怪的顺序执行。
如果这在某种程度上有帮助，这是我用来获取正确 id 的触发器的一部分：（完整代码请单击此处）
select delays.id,product_id,crew_id
into t_lastId, t_product_id,t_crew_id
from delays join line_reasons on delays.line_reason_id = line_reasons.id
where line_reasons.line = t_line order by delays.start_time desc limit 1;
我还应该提到，由于我无法在主系统上创建触发器，我创建了一个基本上将这些值复制到events表中的作业：
id | event_timestamp | event_value | event_attr... |
1 1/1/13 07:00 1 'event started'...
2 1/1/13 07:05 2 'event ended'...
我的触发器在这张events桌子上运行。
一个示例显示了批量的外观以及为什么我的触发器导致插入失败：
| datetime | tagname | value |
1/1/13 07:40:10 tag 1
1/1/13 07:41:05 tag 1
1/1/13 07:40:45 tag 0
如您所见，批量未按正确的时间顺序插入，输出如下：
| id | start_time | end_time | duration | uptime | reason
event1 1/1/13 07:40:10 1/1/13 07:40:10 5 0 xxx
event2 1/1/13 07:41:05 1/1/13 07:40:45 -20s 55s yxy
更新
我再也看不出为什么持续时间和正常运行时间应该是我表中的存储值。让它们即时计算将过度简化很多工作。