Дизайн базы данных для рекламных акций и их типов

Question

Требуется создать таблицу рекламных акций, которая может иметь несколько типов рекламных акций.т. е. купоны, промо-коды, подарки и т. д.

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

Решения в моем уме:

1. Создайте отдельные таблицы для каждого типа продвижения, чтобы учесть связь между Акциями и соответствующей таблицей типов, например: Promotion_Coupon_Relation

2. Удалите ограничение внешнего ключа в таблице продвижения и создайте столбец, в котором будет храниться значение внешнего ключа каждый раз, когда продвижение создается на основе типа.Но в этом случае отношение не будет конкретным и будет определяться только на основе типа продвижения.

Промо-тип:

PromotypeID, PromoTypeDesc (например, купон, промо-код, подарки и многое другое в будущем)

Акция:

PromotionID, PromotypeID, PromotionTypeReferenceID, EffectiveDate, EndDate, Active

Купон:

CouponID, CouponName, CouponCOde, CouponTitle, isActive

PromoCode:

PromoCodeID, PromoCodeName, PromoCodeText, PromoCodeTitle, isActive

Подарок:

GiftID, GiftTitle, GiftDesc, isActive

, пожалуйста, сообщите.

Answer 1

Я вижу два решения

Общие таблицы

Все типы продвижения представлены в одной таблице.Но поскольку детали каждого типа продвижения являются переменными, необходимо создать общие столбцы для хранения таких атрибутов.гм, это было бы отличное место для XML-файла ...

• Продвижение таблицы: promoid, title, ...
• Предложение типа таблицы: promotypeid, name, attribute1name attribute1value,attribute2name, attribute2value ..., имя атрибута, имя атрибута
• Таблица Соотношение типа промо-акции: promotypeid, promoid

Если только один тип может быть связан с повышением, нет необходимости вТаблица соотношения типа продвижение-тип.Просто добавьте промо-тип в качестве основного ключа в Акции.

Конкретные таблицы

Каждый тип промо-акции получает таблицу.

• Настольный рекламный ролик: promoid, title, ...
• Настольный подарок: giftid, name, ...
• Table Coupon: couponid, name, ...
• Таблица промо-акций-подарков: промотип, giftid
• Таблица промо-купонов-связей: промотипов, купонов

Снова таблицы ссылок не требуются, если выдопускается только 1 для каждого типа.

---

Обсуждение

Метод общих таблиц проще на уровне базы данных, но может стать адом в коде.Допустим, у подарка и купона есть дата истечения срока действия, в качестве этой даты вы должны указать имя атрибута, а в качестве значения указать какое-либо значение.Теперь, чтобы запросить эту дату, вам нужно пройти через имена атрибутов.

Answer 2

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

Другие варианты - хранить пары метаданных / значений ключей, поэтому строка будет содержать данные, подобные:

• Первичный ключ
• Внешний ключ для PromotionType
• Тип ключа, например, "PromoType", "CouponName", "PromoCodeText"
• Связанное значение, например, "BoGoF", "Предложение M & S", "Купи один получитьone free "

Они могут быть запрошены и повернуты или возвращены как XML и т. д. Однако всегда есть хит в использовании и рендеринге метаданных.Возможно, стоит подумать о том, куда идут следующие данные и выводить их в формате JSON или XML для дальнейшего использования.