Вы могли использовать DTD HTML и универсальный XML парсинг библиотек.
Лучше всего запустить отдельный сценарий, который работает вечно и отслеживает вашу базу данных . Таким образом, вам не понадобится cron. И не большое количество триггеров.
Но вы, возможно, захотите полностью пересмотреть свой вопрос. Фактически не обязательно обновлять ставки каждую секунду. Вам нужно заполнить только последние x минут / часов, когда кто-то фактически указывает в своем браузере на аукцион или делает ставку вручную. Если это все автоматические ставки, вы можете легко рассчитать форвардные и обратные ставки.
База данных обрабатывает запланированные запросы, не отличаясь от других запросов. Но поскольку многие запланированные запросы содержат операции обслуживания базы данных и таблиц, которые блокируют базу данных, они нередко делают это.
При этом: Поскольку ваша система должна реагировать на действия пользователя, предпочтительный технический способ сделать это - использовать триггеры. На практике это может привести к проблемам с производительностью, когда ваш сайт действительно нагружен - хотя использование запланированного события может вызвать те же проблемы.
Я советую поместить вашу логику в хранимые процедуры и вызывать эти хранимые процедуры из триггеров. Когда вы обнаружите, что триггеры не работают, вы всегда можете удалить триггеры и вызвать хранимые процедуры из задания cron.
Я бы, вероятно, смоделировал решение вашей проблемы с автоматическим назначением ставок немного иначе:
Как насчет подхода, основанного на событиях? Вы сохраняете запросы автоматических ставок своих пользователей, и если кто-то действительно делает ставки на объект, вы обрабатываете ранее поставленные в очередь автоматические ставки.
Это дает следующие преимущества: