• Склейка двух таблиц по сложному условию

    @dummy2002
    Сорри, поторопился
    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;
  • Склейка двух таблиц по сложному условию

    @dummy2002
    Я это к чему, при онлайн-импорте данных в таблицу 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;

    Заметьте, у вас ежесекундно простаивает база, так что триггера будут работать быстро, не нагружая сервер.
  • Склейка двух таблиц по сложному условию

    @dummy2002
    Насколько важны эти два поля для описания предметной области?

    prev_event_timestamp BIGINT UNSIGNED NULL DEFAULT 0 COMMENT 'Дата и время предыдущего эксперимента',
    next_event_timestamp BIGINT UNSIGNED NULL DEFAULT 0 COMMENT 'Дата и время следующего эксперимента',

    Намеренное введение избыточности для оптимизации времени последующих выборок клиентской части? Может, существует возможность онлайн-ввода данных таблиц experiments и random_events? Я это к тому, что ВОЗМОЖНО ваши последующие трудозатраты с поддержанием костылей (схемы с явной избыточностью и хранением времен экспериментов, а не вторичных ключей) СОИЗМЕРИМЫ с организацией онлайн-импорта и последующей эксплуатации нормальной схемы.
  • Склейка двух таблиц по сложному условию

    @dummy2002
    Указанная Вами схема не укладывается в рамки «Нормальной формы» для реляционных баз данных. Естественно, что для поддержания данных в предложенной Вами форме необходимы значительные дополнительные накладные расходы (по сравнению со схемой во второй нормальной форме). Если бы Вы детализировали предметную область, можно было бы предложить Вам оптимизированную схему хранения и заполнения данных.

    По предложенной Вами схеме, если обозначить записи таблицы experiment как E, а записи таблицы random_events как R, то насколько я понимаю, возможен следующий хронометраж генерации новых записей в схеме: {EEREEREER}. Рассмотрим последнюю запись R: она подлежит вставке в таблицу, но значение ее поля next_event_timestamp еще не определено, хотя у Вас оно описано как NOT NULL.