Я, когда делал подобную задачу, рассматривал акции как набор фильтров для объекта с N числовыми характеристиками+ значение(либо число, либо процент от числовой характеристики №1). Т.е. акция "в первую неделю января даем скидку в 10% от суммы заказа, если в заказе есть серебряные ложечки" выглядит как "10% от А, если B (в данном случае тип объекта ) равен 10(заказ), С(в данном случае число дней с 1900.01.01) между XXXX(01.01.2016) и YYYY(07.01.2016) и любая характеристика от D до Z (каждая характеристика - ID одного из товаров заказа) равна 1045 (ID товара "серебряные ложечки")".
Что такое B и что такое C - системе расчета акций без разницы, она получает таблицу объектов и таблицу характеристик объектов "на входе".

Wovan2Кот Матроскин,
Спасибо. Интересно, но не очень понятно. А если "ложечек" больше, н-р, 5. Как эта нотация будет выглядеть?
В БД это одна таблица? С N полями? Что-то по описанию не могу вообразить :-(
"Ложечек больше, например 5" - теперь я не понял. "не меньше 5 ложечек в заказе"? "5 конкретных разных товаров (ложечки, поварешечки, и т.п.)"? Как целиком выглядит условие акции, описание которой Вы не можете себе представить в этой нотации?
"Акция" описывается двумя таблицами - родительской "Акции" и дочерней "Условия". "условия" можно хранить просто "Параметр больше/меньше/большеравно/меньшеравно константы", тогда условие
С(в данном случае число дней с 1900.01.01) между XXXX(01.01.2016) и YYYY(07.01.2016)
разваливается на 2 записи, либо в каждой записи хранить верхнюю и нижнюю границу (тогда условие "Значение параметра больше 5000 " будет выглядеть как "нижняя граница 5000, верхняя - NULL").
На вход модулю расчета акций приходит тоже 2 таблицы (я реализовывал как temporary tables) - "обьекты" и "параметры обьектов". Параметры сравниваются с соответсвующими условиями, если все условия акции для обьекта "сработали" - в поле ActionValue соответсвующей записи таблицы "обьекты" записывается значение акции (для моего примера - берется параметр А, умножается на 0.1). По результатам работы расчета если ActionValue - NULL, то обьект не попал ни под одну акцию.
У меня не могло быть ситуации, чтобы обьект попал под несколько акций сразу (потому что это были не акции, а тарифы), но это не принципиальное ограничение, можно при желании реализовать разное поведение - "брать первую подходящую акцию", "брать акцию с масимальным ActionValue", "суммировать ActionValue разных акций " и т.п.

Wovan2Кот Матроскин,
Сейчас посмотрел внимательнее. Ваш подход позволяет более формализовать условия акции. Если в акции участвует много товарных позиций, то надо для каждого товара прописать однотипные условия?

Необязательно - можно в "условиях" реализовать не только "Больше/меньше", но и, скажем, "один из списка" - структура и логика будут несколько сложнее, зато дублирования меньше(хотя вообще вариант условий "ИЛИ", а не "И" - у меня да, реализовывался дополнительными "техническими" акциями).