Я пишу приложение, которое будет работать в режиме «только чтение» на клиентской БД, поэтому я не могу ничего изменить в структуре БД, но я также не могу быть обвинен в структуре :) И я не уверен, что это должно быть решено на уровне БД или выше ...
У меня есть таблица PostgreSQL events, которую можно упростить до следующего вида:
id UUID PRIMARY KEY
owner_id INT
previous_event_id UUID FOREIGN KEY REFERENCES (id) ON events
created_at TIMESTAMP
Как видите, события связаны полем previous_event. Это не избыточно, потому что один и тот же пользователь может одновременно иметь несколько «потоков» событий, поэтому это не просто вопрос упорядочения по времени создания.
Теперь я должен извлечь из него отдельные цепочки событий .
Цепочка событий в нашей терминологии - это набор событий, имеющих одинаковый owner_id, они связаны друг с другом previous_event_id, а разница между их created_at отметками времени меньше X minutes.
Я почти уверен, что проверка по очереди на преемника / предка и разницу во времени потребует возрастов и тысяч запросов к БД в секунду. Каков будет лучший способ сделать это? Я вижу следующие сценарии:
Пока не разбиваемся на цепочки, просмотрите весь поток событий для конкретного пользователя, не смотря на разницу во времени (практически: для указанного user_id получите все события, связанные друг с другом previous_event_id) .
Получите количество цепочек событий для user_id == A (практически: для конкретных user_id, получите количество событий, которые имеют previous_event_id NULL (что тривиально), ИЛИ, которые имеют created_at отметка времени больше, чем (отметка времени предыдущего события + X), где предыдущее событие указано previous_event_id) .
Получить цепочку событий, начатую событием с id == B (практически: получить все события, которые имеют то же user_id, что и указанное событие, связаны с previous_event_id и имеют created_at разницу меньше, чем X ).
Я не уверен насчет целевого объема данных, поэтому не могу ничего предположить. Единственное, что мне пришло в голову - это выборка данных в пакетном режиме, а затем попытка обработать их в памяти, найти правильный конец цепочки (и получить больше данных, если не найден), но мне это кажется уродливым ...