Как спроектировать покупку абонемента?

Question

[Mick Coder]

Привет!) Проблема - проектирования функционала типа интернет магазина, но в качестве товара, "абонемент", который позволяет пользователю сайта иметь доступ к определёным частям сайта (Например к видеоурокам и тп.). Цена на абонемент формируется как за 1 шт. 1 шт - соответствует 1 Дню. Также возможна реферальна програма т.е. клиент пришел на сайт по рекомендации.
Меня интересует как оптимально спроектировать такую систему, например:
1) Где хранить и агрегировать сумарное количество абонементов и как отследить сколько дней до окончания например аккаунта PRO осталось?
2) Как лучше организовать реферальную систему ?

Сейчас есть такие таблицы
ORDER (id_order, id_abonament, id_client, amount(количество абонементов - дней), status, date_order)
ABONAMENT (id_abonament, price, options)
CLIENT (id_client, name, email)
LOYALTY_JOURNAL (id, id_client, login_ref (логин пользователя который рекомендовал))

Мне не так интересно полное решения, как дискусия (Воплощать в реальный код даную задачу не буду, интересно только проектирования). Давайте обсуждать!

Comments

[Сергей Соколов]

Озадачен похожей задачей. Плюс покупки дискретных услуг: оплатил 5x – может пять раз выполнить некое премиум действие. Но их считать проще, отдельным полем у юзера.
А вот что выделаете, если есть разные по уровню тарифные планы: беспл., Про и Суперпро.
По середине оплаченного срока Про, клиент покупает (внезапно) план СуперПро на месяц.

1. Месяц вы предпочитаете считать календарный, 30 или 31 день?
   
2. Закончился месяц СуперПро – клиент докатывает полмесяца на просто-Про?

[Mick Coder]

1) Думаю месяц можно расчитать как в календаре) Например если купил аакаунт на месяц Март то 31 день
2) Может добавить сутность аккаунт?! Или переключать например поле type в таблице юзера, но при этом выводить ему предупреждения что при покупке аккаунт будет обновлен

Answer 1

[Максим Кудрявцев]

Суммарное количество абонементов.
У нас есть таблица "Юзер" и таблица "Абонемент"(тут срок и цена). Создаем третью таблицу "ЮзерАбонемент", в которой будет записан id юзера, id абонимента и дата покупки абонемента.

Сколько дней осталось до окончания PRO-статуса.
Парсим "дата покупки абонемента" и "срок абонемента" из БД, прибавляем одно к другому и сравниваем с текущей датой. Если текущая больше - снимаем юзеру статус PRO. Разумеется этот скрипт ставим в cron и запускаем каждые 24 часа

Как лучше всего реализовать реферальную систему
1)С тех. стороны - формируешь ссылку example.com/index.php?refid=1 Refid - есть id пользователя в твоей БД.
2)Если юзер зашел по такой ссылке - установить ему cookie на 30 дней, например
3)При регистрации проверять, если есть установленный кук, значит засчитать этого пользователя как реферала другому.

С RefID - самый простой пример. Можно соединить id + дата регистрации в unixt time и взять потом от этой вещи sha1. Этот вариант считается более защищенным, все таки светить id юзеров не считаю правильным.

UPD
Также рекомендую почитать Вам про нормальные формы БД. Если бы Вы понимали их - первого вопроса у Вас не возникло бы. На практике широко используются только первые три. С четвертой и далее - уже разного рода специфичные решения.

Comments

[Mick Coder]

Спасибо! Первым вопросом я хотел подчеркнуть что клиент может несколько раз покупать абонемент и на сколько угодно дней. Например если он 26.03.2015 первый раз купил на 7 дней, а потом ещё на 4 дня. то аккаунт будет действовать до 06.04.2015.

[Mick Coder]

Как быть если Ордеров (покупок) несколько? Они же сделаны в разное время, и может быть такое что предыдущий абонемент уже закончился а мы всё равно суммируем

[Максим Кудрявцев]

Таблица ORDER.
1)Сегодня я взял абонемент на 2 дня - добавить строку
2)Завтра я понял, что мне нужно еще 3 дня и оплатил их - UPDATE ранее добавленной строки. В WHERE, разумеется, у нас id текущего юзера
3)Срок абонемента истек - удалить строку из таблицы.

[Mick Coder]

Ну да можно и так... но виглядет как костыль.. например если будет нужна история Покупок? всё же затирается.

[Максим Кудрявцев]

Mick Coder: я Ваше техническое задание не вижу. Нигде выше про историю покупок ничего у Вас нет. А если ее у Вас нет в ТЗ, то нафиг ее вообще реализовывать? Я предложил самый простой вариант, а усложнять его можно до бесконечности...

Answer 2

[Валерий Рябошапко]

На мой взгляд, лучше организовать схему хранения так.

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

CLIENT (
    id_client,
    name,
    email,
    abonement_expiration,
    referer )

Таблица со списком заказов. Нужна в первую очередь для бухгалтерии, история заказов и всё такое.

ORDER (
    id_order,
    id_abonament,
    id_client,
    amount,
    status,
    date_order)

Покупка абонемента оформляется транзакцией, которая состоит из (лень писать код :-)

1. занесения заказа в таблицу с заказами,
   
2. извлечения текущей даты истечения из таблицы с клиентами,
   
3. подсчёта новой даты с учётом стоимости абонемента,
   
4. занесения новой даты истечения в таблицу с клиентами.
   

Операции 2-4 можно оформит одним запросом, но всё четыре в любом случае должны быть одной транзакцией.

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

Организация реферальной программы - дело не хитрое. Дополнительное поле в таблице с пользователями позволяет без труда найти реферера и рефералов. Идея с куками, которую предложил Максим Кудрявцев - отличное решение, лучше не придумаешь.