Сорри, поторопился
select e.id into tmpLastEvent from experiment e where e.event_timestamp < :NEW.event_timestamp;
нужно дополнить до
select e.id into tmpLastEvent from experiment e where e.event_timestamp < :NEW.event_timestamp and rownum = 1 order by event_timestamp desc;
Я это к чему, при онлайн-импорте данных в таблицу experiment капают записи не чаще раза в секунду. Для таблицы random_event опять же при онлайн-импорте вы в триггере на вставку можете сделать подзапрос к experiment типа (семантика для Oracle)
CREATE OR REPLACE TRIGGER XXX.BI_RANDOM_EVENT
BEFORE INSERT
ON XXX.RANDOM_EVENT
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
DECLARE
tmpLastEvent NUMBER;
BEGIN
tmpLastEvent := 0;
select e.id into tmpLastEvent from experiment e where e.event_timestamp < :NEW.event_timestamp;
:NEW.prev_event := tmpLastEvent;
:NEW.next_event := NULL;
end BI_RANDOM_EVENT;
Естественно, здесь указаны вторичные ключи, а не сами значения DATETIME для записей из experiment. Чтобы закрыть NULL-значения в random_event понадобится триггер для вставки в таблицу experiment
CREATE OR REPLACE TRIGGER XXX.BI_EXPERIMENT
BEFORE INSERT
ON XXX.EXPERIMENT
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
update random_event set next_event = :NEW.id where
next_event is NULL;
end BI_EXPERIMENT;
Заметьте, у вас ежесекундно простаивает база, так что триггера будут работать быстро, не нагружая сервер.
Насколько важны эти два поля для описания предметной области?
prev_event_timestamp BIGINT UNSIGNED NULL DEFAULT 0 COMMENT 'Дата и время предыдущего эксперимента',
next_event_timestamp BIGINT UNSIGNED NULL DEFAULT 0 COMMENT 'Дата и время следующего эксперимента',
Намеренное введение избыточности для оптимизации времени последующих выборок клиентской части? Может, существует возможность онлайн-ввода данных таблиц experiments и random_events? Я это к тому, что ВОЗМОЖНО ваши последующие трудозатраты с поддержанием костылей (схемы с явной избыточностью и хранением времен экспериментов, а не вторичных ключей) СОИЗМЕРИМЫ с организацией онлайн-импорта и последующей эксплуатации нормальной схемы.
Указанная Вами схема не укладывается в рамки «Нормальной формы» для реляционных баз данных. Естественно, что для поддержания данных в предложенной Вами форме необходимы значительные дополнительные накладные расходы (по сравнению со схемой во второй нормальной форме). Если бы Вы детализировали предметную область, можно было бы предложить Вам оптимизированную схему хранения и заполнения данных.
По предложенной Вами схеме, если обозначить записи таблицы experiment как E, а записи таблицы random_events как R, то насколько я понимаю, возможен следующий хронометраж генерации новых записей в схеме: {EEREEREER}. Рассмотрим последнюю запись R: она подлежит вставке в таблицу, но значение ее поля next_event_timestamp еще не определено, хотя у Вас оно описано как NOT NULL.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
select e.id into tmpLastEvent from experiment e where e.event_timestamp < :NEW.event_timestamp;
нужно дополнить до
select e.id into tmpLastEvent from experiment e where e.event_timestamp < :NEW.event_timestamp and rownum = 1 order by event_timestamp desc;