Нет, скорее автор имел ввиду не это. Предположим крон вызывает скрипт и обращается к базе в 12 часов 12 минут. И у нас есть задача, которая должна отработать в это время. Мы разбиваем текущее время на составляющие части и смотрим все записи, в которых есть подходящие записи. Среди таки например будет: 12 12, * *, * 12, 12 * и т.д. Т.е. фактически задача стоит в том, чтобы появилась возможность указать время выполнения постинга не в конкретное время или интервал, а как в кроне (например каждую 12ую минуту 13ого часа по средам). С использованием Date() тривиальным путем этого не добиться (по крайней мере мне быстрого решения не приходит на ум, но с удовольствием выслушаю предложения). В своем первом комментарии не до конца понял автора и поэтому спешу извиниться.
Может я чего-то не понял, но чем принципиально будет отличаться перебор всей базы по времени от перебору по такой регулярки? Все равно все данные будут просматриваться, только тут еще и велосепед в коде? Поправьте, если я не прав.
В самом запросе будут участвовать: при определении диапазонов используются только первичные ключи, в джойнах вместо диапазона вида «WHERE x > 10 AND x <20» мы уже напишем «WHERE id>1000 AND id<2000», где id=1000 — элемент со значением 10 и максимальным id, а id=2000 — элемент со значением 20 и минимальным id (для случая монотонного возрастания id и x). Вся суть в том, чтобы вместо столбцов без индексов использовать первичные ключи. Но этот способ подходит только если данные монотонно возрастают\убывают, как уже заметил konsoletyper.
Можно обойтись и без джойнов, но тогда мы бы не смогли получить результат одним запросом и пришлось бы выполнить кучу кода на php с огромным объемом данных. Да, много подготовительной работы, но зато всего один запрос для получения ответа.
Проект достался мне уже таким. Делать еще один индекс для такой таблицы это довольно проблематично. Займет кучу времени и не факт, что его польза потом проявится где-то еще кроме этой задачи. И да, в таблицы делается довольно много вставок.
Задачу ставлю не я. Обычно проектируется и разрабатывается система, а потом начальство проявляет желание получить кучу красивых графиков по таблицам, которые не были спроектированы для такой задачи.
Про монотонное возрастание верно. Но х и id не обязательно должны возрастать. Один столбец может возрастать, а второй убывать. Суть от этого не поменяется, диапазон мы тоже сможем найти.
Дырки в таблице безусловно есть. Это решалось тем, что если выбирался id, который попадает на дырку, то выбирался ближайший элемент и его значение.
Проект достался мне уже таким. Делать еще один индекс для такой таблицы это довольно проблематично. Займет кучу времени и не факт, что его польза потом проявится где-то еще кроме этой задачи. И да, в таблицы делается довольно много вставок.
Задачу ставлю не я. Обычно проектируется и разрабатывается система, а потом начальство проявляет желание получить кучу красивых графиков по таблицам, которые не были спроектированы для такой задачи.
Про монотонное возрастание верно. Но х и id не обязательно должны возрастать. Один столбец может возрастать, а второй убывать. Суть от этого не поменяется, диапазон мы тоже сможем найти.
Дырки в таблице безусловно есть. Это решалось тем, что если выбирался id, который попадает на дырку, то выбирался ближайший элемент и его значение.