Тут, насколько я понимаю, алгоритм такой: нужно выбрать все записи, отсортированные по возрастанию start_date (индекс этому способствует), а потом из них выбрать те, у которых end_date > следующего start_date, либо start_date < предыдущего end_date.
Но я плохо знаю SQL, в частности, не знаю как в нём оперировать с "предыдущей" и "следующей" записями в выборке. Это мощный язык, наверное, в нём предусмотрено что-нибудь эдакое, но я не в курсе. Ну и ещё можно с хранимой процедурой заморочиться, наверное.
-- Вт сен 23, 2025 16:13:41 --
Сейчас подсмотрел, в SQL есть такие штуки как LAG и LEAD, с помощью которых можно достучаться до предыдущей и следующей записи.
Наверное, если LLM про них подсказать, она выдаст корректное решение.
В общем да, примерно так и работает. Задачу можно немного по-разному сформулировать, в том числе так, чтобы было решать не очень удобно. Я специально выбрал максимально удобный вариант, чтобы у ИИ было меньше возможностей отвертеться. Суть в том, что аналитическая функция в SQL рассчитывается для плавающего окна, задавать границы окна можно самыми разными способами, и вся соль этой задачи в том, чтобы описать это окно.
Код:
SELECT log_id, overlapping_processes
FROM (
SELECT
log_id,
start_date,
end_date,
LAG(end_date) OVER (ORDER BY start_date) as prev_end_date,
COUNT(CASE WHEN start_date < LAG(end_date) OVER (ORDER BY start_date)
THEN 1 END)
OVER (PARTITION BY NULL ORDER BY start_date ROWS UNBOUNDED PRECEDING) as overlapping_processes
FROM log_table
WHERE end_date IS NOT NULL
)
WHERE overlapping_processes > 0
ORDER BY log_id;
Это уже намного лучше! (а если бы вы еще и форматировали код нормально, было бы вообще замечательно)
Не уверен, правда, что этот код заработает, а если заработает - вернет хотя бы приблизительно правильный результат. Но это точно шаг в правильном направлении. Хотя не исключено, что случайный
Проблема запроса в том, что он использует LAG, а эта функция берет данные со следующей строки. Но ниоткуда не следует (при моей постановке задачи), что если процесс тормозит, то он будет тормозить только до начала следующего. Он может и дольше тормозить. Я даже на это намекнул - "для каждого log_id вывести
количество новых процессов". То есть оно может быть разным.
То есть, нам надо:
отсортировать по полю
start_dateначало окна - текущая строка
конец окна - строка, где
start_date больше чем
end_date текущей
функция - count (ищем количество строк), и вычесть 1, потому что посчитается текущий процесс
Ответ в спойлере.
(Оффтоп)
Код:
select *
from (select log_id, count(*) over (order by start_date range between current row and end_date - start_date following) - 1 cnt
from log_table)
where cnt > 0
Причем он же, собака, знает нужный синтаксис и может объяснить, почему правильное решение работает - если ему это решение показать. А если не показывать, можно бесконечно повторять - джойн не нужен, достаточно к таблице один раз обратиться, и т. п., он будет настойчиво пихать разные варианты этого решения.
Достаточно один раз сказать "не думай о розовом слоне". Для чата эта ситуация куда как безнадежнее чем для людей. Особенно, если это новый чат, то в контекстном окне будут эти слова и от них пойдут семантические связи по наработанным в процессе обучения. Может чаты плохо обучены и надо дообучать на конкретном примере, но придумывать то чему не обучали это немного другой навык. А так же думать о том, о чем не просили, иметь свою цель.
Это все неважно. Детали, почему именно он не справляется, пусть его разработчики анализируют. А я человек простой: слышу заявление разработчиков, что их ИИ достиг уровня PhD - иду проверять
Ну, пока не достиг.
Мне пока приходит такая аналогия в голову: стереотипный гений-вундеркинд из художественной литературы и кино, который уже слышал много чего с переднего края всех наук сразу, но с трудом завязывает себе шнурки и не может приготовить завтрак.
25.09.2025, 22:34 
