> Как правильно подойти к такого рода задачам
Лет 10 тому назад я сделал это таким способом. В базе таблица рассылок и
таблица адресатов. В таблице рассылок шаблон сообщения и параметры
рассылки (мне нужно было обеспечить щадящий режим для sendmail поэтому
там у меня были настройки скорости посылания писем).
В таблице адресатов адрес и несколько полей (фамилия, имя и др.). Также
у каждой записи были поля status и senddate. Senddate обновлялся после
отправки. В статус записывалось одно из 4 значений. 0 — письмо не
отослано, 1 — письмо в процессе отсылки, 2 — письмо отослано, 3 — не
удалось отослать. (Я не помню было ли поле с сообщением об ошибке).
Ах да, еще были требования — никаких длинных транзакций и поменьше запросов.
Подготавливал список адресатов SQL запросом INSERT ... SELECT, выбирал
для отправки по N адресатов (кажется по 20) запросами SELECT TOP N ...
WHERE status = 0 ORDER BY id;
После выборки тут же помечал выбранные статусом 2
UPDATE ... SET status = 2 WHERE ID IN (...)
Генерировал сообщения непосредственно перед отправкой. Мне все равно
нужно было "спать" чтобы выдерживать график. Поэтому я генерировал, спал
сколько нужно, отправлял, генерировал следующее и опять спал.
По окончанию порции из N писем я обновлял БД, и все по-новой.
Года 3 тому назад мне приходило письмо от того кода.
Недостаток подхода — при падении N писем оставались в неизвестном
состоянии. Полечить можно установкой N = 1, но тогда на каждое письмо
будет 3 запроса в базу.
Posted via RSDN NNTP Server 2.1 beta