Да, именно такой вариант и был предложен выше. Сейчас как раз прорабатываю его детали. Только вот этот скрипт придется запускать слишком часто — 1 раз в секунду. Также здесь есть еще один подводный камень: снижается стабильность системы. Что произойдет, если по каким-то причинам скрипт не будет запущен? Ну, скажем, сервер перезагружался.
Ничего не происходит в 12-00. Просто при выборке объявлений к показу учитывается расписание и даты предполагаемого окончания средств на счетах пользователей. Это работает, но это сложно.
Не существует такого события как «запуск показа объявления по расписанию». Например, пользователь записал включение объявления на 12:00 завтрашнего дня. Завтра в 12-00 не запускается никакой скрипт, никакое событие не вызывается
Я уже готов отказаться от всего что используется сейчас :) и от РНР, и от всего. Я осознаю всю сложность каши, которую заварил, но решение все-таки требуется. Ирония в том, что сейчас посекундная тарификация работает и стабильно. Единственное что мне не нравится — это чрезмерная сложность (логическая) получившейся системы
Да, прямо посекундная тарификация. Prepaid с элементами postpaid (сейчас не говорю об этом, чтобы не загромождать объяснения, но сути это не меняет). Вот вся проблема как раз в «счет проверяется». Как узнать текущий остаток пользователя в данную секунду?
Второй способ не совсем подходит, т.к. он еще сложнее того, что реализовано сейчас — рассчитывание даты окончания денег на счете пользователя на основании текущих включенных объявлений и объявлений, которые будут включены в будущем по расписанию.
Пользователям нравится текущая система. Но ее сложно развивать. От погоды на марсе время не зависит. Но пользователем может быть составлено расписание включения-отключения. А эти вещи уже в событийную модель не очень вписываются. Приходится делать так, как предложил edogs: пересчитывать предполагаемую дату окончания размещения (время когда на счете пользователя останется 0 рублей) каждый раз, когда что-то меняется. Но опять-таки, учитывая расписание включения-отключения это становится адской конструкцией.
Сейчас реализована посекундная тарификация. Это действительно необходимо. Реализована она как раз на событийной модели. Но все усложняется тем, что есть такие события, которые также не предсказуемы. Например, включение объявлений по расписанию, которое задается (и изменяется) пользователями. Все это сделано, но поддерживать такую конструкцию весьма тяжело. Отсюда и сабж…
Именно таким образом и решено сейчас: у объявления есть параметр «дата окончания срока действия», который пересчитывается при любом внешнем воздействии на состояние счета пользователя. Это как раз п.2 из «плохих вариантов».
Хорошо, я немного смещу акценты в задаче: как в любой момент времени узнать реальный остаток на счете пользователя?
Хорошо. Но я несколько упростил задачу, и видимо все же нужно представить ее в более полном виде.
Отзывы бывают положительные и отрицательные. И в форме несколько галочек:
— «искать только с отзывами»
— «искать только с положительными отзывами»
При таком раскладе я не смогу сделать обычный атрибут (если конечно не вводить дополнительные столбцы в таблицу товаров: comments_count, positive_comments_count)
