Схема данных продуктов членства - PullRequest
Новая
       21

Схема данных продуктов членства

0 голосов
/ 30 июля 2009

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

Проблема заключается в том, что наши продукты для членства повсюду. У нас есть 4 типа организаций, которые могут присоединиться к нашей организации. Существует отдельный ценовой график для каждого типа организации. Атрибуты организации определяют цену, которую они будут платить по графику (например, если их доход составляет от 2 до 5 миллионов долларов, они платят 2000 долларов). Атрибуты, используемые в каждом ценовом графике, различны. Например, предприятия платят в соответствии с их годовым доходом, в то время как школы платят в соответствии с их эквивалентом зачисления учащихся на полный рабочий день - который мы рассчитываем, когда члены школы предоставляют нам свои номера учащихся на полный и неполный рабочий день. Чтобы сделать его более сложным, существуют дисконтные программы (например, 15 месяцев по цене 12 для раннего продления, скидки для школ с ограниченными ресурсами и т. Д.). Затем участники имеют возможность покупать несколько терминов одновременно, и мы иногда позволяем людям покупать пропорциональные частичные условия (месяц - наименьшая единица.)

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

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

Любая другая информация также будет принята с благодарностью. Спасибо!

1 Ответ

1 голос
/ 30 июля 2009

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

Например: 

CREATE TABLE payment(
     memeber_id INT,
     payment INT,
     expected_date DATE,
     payment_date DATE);

 CREATE TABLE credit(
     memeber_id INT,
     credit INT,
     last_movement` INT,
     next_movement INT,
     last_movement DATE,);

 CREATE TABLE member(
     id INT,
     membership_plan INT,
     ...)

Кроме того, например, вы можете легко запросить, есть ли у участника кредит, ушел, заплатил ли он, что ожидалось, и т. Д. Бизнес-правила устанавливаются в программном обеспечении поверх этих данных. Для каждого плана членства должны быть правила, регулирующие его по-разному.

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

CREATE TABLE member_attributes(
         membership_type INT,
         attribute VARCHAR(30), --for example 'Monthly Pay', 'Membership duration'
         value INT)
...