Есть таблица с покупками. Для покупок определенного типа начисляются бонусные баллы. Исходную таблицу изменять нежелательно (добавить в нее флаг "Обработана"). Нужно не допустить дублирования бонусов (т.е. не обрабатывать одну покупку дважды). Покупок задним числом не бывает.
Подскажите, как будет правильнее?
1. Ежедневно запускается скрипт, обрабатывает покупки за предыдущие сутки.
2. Идентификаторы обработанных покупок сохраняются в отдельной таблице и из таблицы покупок извлекаются только те покупки, которые еще не были обработаны.

Второй вариант как бы надежнее, но мне кажется избыточным.

________________________
Мы смотрим с оптимизмом...
...в оптический прицел.

Да, это sequence.
Возможно это будет оптимальным.
В первом варианте мне не нравится вероятность проблем если вдруг ежедневный запуск не сработает, а во втором варианте не нравится слишком большая избыточность данных.

-2-Судя по вопросу, история когда за что начисляли не хранится.
Я думал, но не вижу особого смысла хранить историю начисления бонусов.
Список покупок в прошлом не изменяется и для сверки бонусы всегда можно пересчитать ретроспективно.
Под проблемами я подразумевал, что по какой-то причине ежедневный скрипт может не отработать и тогда начисления за этот день будут пропущены и восстанавливать их нужно будет вручную. При втором варианте такой проблемы не будет, пропущенные покупки будут обработаны при следующем запуске скрипта.

andrey_anonymousСмысл осознается в момент, когда возникают разногласия по начислениям.
Например? Я пытался себе представить такую ситуацию, но так и не придумал.
Есть покупки за прошлые периоды, есть соответствующие этим покупкам начисления бонусов.
Допустим есть разногласия по начислениям бонусов за вчерашний день, в этом случае нужно поднять историю покупок (которые регистрируются детально), просуммировать их вручную, посчитать бонус и сверить посчитанное с начисленным.
Но исходные данные, по которым начисляются бонусы, одни и те же, как на момент расчета, так и на любой другой момент в будущем. И результат будет одним и тем же, если только не предполагать, что CPU разучился выполнять арифметические операции.
Смысл хранить историю начислений был бы в том случае, если бы на расчет влияли параметры помимо исходных данных. Но в данном случае формула начисления бонусов полностью детерминированная.

andrey_anonymousЕсли идентификаторы в исходной таблице назначаются sequence, то можно хранить протокол запусков с указанием диапазона обработанных id
А как лучше проверять диапазоны?
left join с последующей проверкой на is null?
Или not exists?