SELECT
m1.recdate, m1.rectime, m1.equip, m1.reason,
m2.recdate, m2.rectime, m2.downtime
FROM main AS m1
LEFT JOIN main AS m2
ON m2.num > m1.num AND m2.equip = m1.equip AND m2.state = 'ПУСК' AND m1.state = 'СТОП'
Так вы получаете по каждому СТОПу все ПУСКи по этому оборудованию после него.
Осталось сгруппировать по СТОПам и выбрать первый же ПУСК.
У строк id есть? По нему можно и сгруппировать, и выбрать ближайший.
Евгений, он утрирован до бессмысленности. Оптимизация работы с БД - это уменьшение количества запросов и их сложности. Разбирать оптимизацию на примере одной записи - все равно, что обсуждать архитектуру на примере одного кирпича.
romserg, я выше уже говорил: джойнишь все ПУСКи позже этого СТОПа, группируешь результаты по конкретному СТОПу и выбираешь к нему самый ранний ПУСК.
А лучше, конечно, просто сделать связь еще во время записи и не мучить базу.
Евгений, пример действительно нагляден: ты страдаешь размышлизмами о базе и приводишь код, который с базой вообще не работает. До оптимизаций и мечтаний о хайлоаде неплохо бы сначала разобраться в том, что делаешь, иначе все эти оптимизации перехерятся буквально парой банальных косяков.
Антон Р., он ползает с микрометром по фотографии тени паровоза. Судя по коду, весь этот апофеоз самоудовлетворения - вокруг одной-единственной записи, причем не факт, что она вообще сохраняется в базу.
akelsey, настраиваете exclude, чтобы не трогать лишнее, делаете копию чистых папок, а потом с этим exclude и командой -n (не копировать изменения, просто показать, что изменилось) смотрите, какие нынешние файлы отличаются от бэкапа.
Либо не смотрите, а делаете что-то с этим простым текстовым выводом то, что вам заблагорассудится.
romserg, и в третий раз пытаюсь донести до вас очевидное: ни по какому полю ОДНОЙ записи нельзя сказать, куда она ближайшая. Нужно сравнивать с другими записями. А джойн берет подряд по одной записи из каждой таблицы и больше ничего сравнивать не собирается.
Кабы у вас хотя бы equip был уникальным для каждого СТОПа - можно было бы джойнить с выборкой, сгруппированной по нему, и выбранным минимальным значением. Но у вас эта выборка получается уникальной для каждого СТОПа, джойн тут ничем не поможет. Разве что после него собрать все, что он наджойнил, и выбрать из этого нужное.
romserg, вам надо не одну, а одну из.
У вас нет четкого условия, которое при сравнении двух строк в таблице может вам сказать без анализа других строк, что они друг другу подходят.
romserg, лучше бы внести изменения в систему: добавить поле привязки, при записи каждого ПУСКа определять предыдущий СТОП и связывать их сразу, чтобы потом не искать.
sergeyiljin, смотря какой веб.
Дергать API курлом не сложнее, чем в Пыхе, например.
Вот если нужно что-то фильдеперсовое, через boost::asio, например... но запрос ТС на это не особенно похож ;)
Будьте любезны, приподнимите клавиатуру над головой и несколько раз резко опустите, приговаривая "и так будет с каждым, кто советует использовать в пыхе глобальные переменные!!!". Спасибо.
Так вы получаете по каждому СТОПу все ПУСКи по этому оборудованию после него.
Осталось сгруппировать по СТОПам и выбрать первый же ПУСК.
У строк id есть? По нему можно и сгруппировать, и выбрать ближайший.