romserg, тут до полного запроса, который выдаст то, что вам нужно, еще как до Луны раком - даже если я правильно напишу этот, он всего лишь выдаст номер записи, а не ее содержимое. Сделайте уже нормальную связь между полями и не морочьте ни мне, ни себе голову.
Хотите поупражняться в зубодробительных запросах - вас ждет sql-ex.ru с подобными задачами.
На практике, правда, всегда оказывается лучше до такого не доводить, соблюдая KISS,
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, например... но запрос ТС на это не особенно похож ;)
Хотите поупражняться в зубодробительных запросах - вас ждет sql-ex.ru с подобными задачами.
На практике, правда, всегда оказывается лучше до такого не доводить, соблюдая KISS,