MySQL порядок элементов в `trigger after insert`

Question

Мне нужно создать триггер, который принимает плоский источник события и преобразует его в строку с start_time и end_time.

Есть две системы и работа, которая передает данные от одного к другому:

________   _________ 
|  | Job | Destiny | 
| Source | -----> |   | 
|________| data |_Trigger_| 

Внутри судьбы, есть две таблицы:

____________________    ________________________ 
|     | 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: (Для полного кода нажмите here)

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 

Update

Я не вижу причин, почему больше продолжительность и время безотказной работы должна быть сохраненное значение в сторона мой стол. Если бы они были рассчитаны на лету, это упростило бы большую работу.

Answer 1

Я не знаю, если я очень хорошо понимаю, но

WHERE end_datetime > start_datetime 

не поможет?

таким образом вы не будете соответствовать равным или отрицательным временам.