Как я могу моделировать данные и логику в базе данных?

Question

Я работаю над веб-приложением для журнала, которое позволит пользователям входить в систему и обновлять свои подписки в Интернете.Эти подписки обновляются на основе набора правил, и я хотел бы получить некоторые идеи / рекомендации по настройке этих правил.

Это веб-приложение взаимодействует с внешней (сторонней) системой, котораяесть данные для подписчика.Когда подписчик входит в систему, веб-приложение получает пакет информации от этой сторонней системы, включая число, называемое «идентификатором определения подписки», которое (якобы) обозначает тип подписки, который имеет подписчик.Этот тип подписки может устареть на несколько лет, поэтому веб-приложение содержит набор «спецификаций заказа» (хранящихся в базе данных), который состоит из текущих параметров подписки, а также информацию, такую ​​как текущий тариф (поэтому цена может бытьпоказывается пользователю в форме заказа).

Моя текущая идея состоит в том, чтобы создать таблицу идентификаторов определений подписки, которая сопоставляется со спецификацией заказа, которой обновляется данный идентификатор определения подписки.Например, идентификатор определения подписки может обозначать годовую подписку десять лет назад, которая тогда стоила 39,99 долларов США;в базе данных это будет соответствовать текущей спецификации заказа , которая будет иметь текущую цену $ 59,99.

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

1. Если это подписка на 1 год, он возобновит использование (текущей) подписки на 1 год.
2. Если это годовая подарочная подписка со скидкой, и подписчик не продлевает какие-либо другие подписки, он будет продлен как (текущая) 1-летняя полная подарочная подписка.
3. Если это 1-годовая подарочная подписка со скидкой, и подписчик продлевает другие подписки, она будет продлена как (текущая) 1-летняя подарочная подписка.

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

Чтолучший способ смоделировать эту комбинацию данных и логических правил?

Answer 1

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

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

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

Answer 2

Обычно это не то, что я бы предложил, но , потому что существует только один идентификатор определения подписки и .лет (поэтому это стабильное бизнес-правило), я предлагаю жестко программировать поведение этого идентификатора.