запощу-ка здесь, вроде как для .net тоже актуально:


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

plans(name, price, how_many_months)
orders(name, plan_id, user_id)
payments(order_id, status, date)

в payments в status может быть pending, canceled, paid, refund, что-то еще.

никак не соображу -- этого достаточно? легко ли будет определить какой сейчас текущий plan у пользователя отфильтровав payments, которые paid, и его характеристики: продолжительность, когда начинается, когда кончается и т.п.?
или нужно еще что-то ввести? а если пользователь купит 2 плана, чтобы когда один закончился, сразу начал действовать второй?


повторюсь, что не хотелось бы денормализовывать схему путем добавления данных, которые итак могут быть расчитаны путем join'ов.

Здравствуйте, sin_cos, Вы писали:

_>нужно спроэктировать систему тарифных планов, их покупки, продления, отмены и т.д. то есть, схему базы данных.
Не нужно. Получится сферический конь в вакууме.

Нужно для начала описать операции в системе, тогда схема БД станет очевидной.

Здравствуйте, gandjustas, Вы писали:


G>Нужно для начала описать операции в системе, тогда схема БД станет очевидной.

есть планы, есть пользователи, пользователь может купить план на какое-то время. все.

Здравствуйте, sin_cos, Вы писали:

_>Здравствуйте, gandjustas, Вы писали:


G>>Нужно для начала описать операции в системе, тогда схема БД станет очевидной.

_>есть планы, есть пользователи, пользователь может купить план на какое-то время. все.

Для разминки:

Смена плана (запланированная / по запросу пользователя / контрагента, ввиду отзыва плана, автоматический перевод при закрытии плана)?

Модификаторы по лимитам / по времени / по расположению пользователя / по ресурсам etc?

Тарификация (шкалы, единицы тарификации, область применения тарификации)? Тарификация части услуг по планам контрагентов? Режимы триала / промоакций?

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

Эт только навскидку, что вспомнилось пока писал.

Я уж молчу про то, что всё это (и ещё с десяток вариантов) должны вводиться за десять минут неуверенным оператором word после пьянки в пятницу без вмешательства программиста. Что тож накладывает определённые ограничения

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, sin_cos, Вы писали:

_>>Здравствуйте, gandjustas, Вы писали:


G>>>Нужно для начала описать операции в системе, тогда схема БД станет очевидной.

_>>есть планы, есть пользователи, пользователь может купить план на какое-то время. все.

S>Для разминки:

S>Смена плана (запланированная / по запросу пользователя / контрагента, ввиду отзыва плана, автоматический перевод при закрытии плана)?

S>Модификаторы по лимитам / по времени / по расположению пользователя / по ресурсам etc?

S>Тарификация (шкалы, единицы тарификации, область применения тарификации)? Тарификация части услуг по планам контрагентов? Режимы триала / промоакций?

S>Про покрытие платёжки даже начинать не буду. Но про обещанный платёж и программы поощрения за лояльность упомянуть таки стоит.

S>Эт только навскидку, что вспомнилось пока писал.

S>Я уж молчу про то, что всё это (и ещё с десяток вариантов) должны вводиться за десять минут неуверенным оператором word после пьянки в пятницу без вмешательства программиста. Что тож накладывает определённые ограничения

что так сложно? какие контрагенты. план, у него есть кол-во дней и цена. смены плана нет. все.

Здравствуйте, sin_cos, Вы писали:

_>Здравствуйте, gandjustas, Вы писали:


G>>Нужно для начала описать операции в системе, тогда схема БД станет очевидной.

_>есть планы, есть пользователи, пользователь может купить план на какое-то время. все.

1) users (id, name)
2) plans (id, name, days, price)
3) orders (userid, planid, date)
все.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, sin_cos, Вы писали:

_>>Здравствуйте, gandjustas, Вы писали:


G>>>Нужно для начала описать операции в системе, тогда схема БД станет очевидной.

_>>есть планы, есть пользователи, пользователь может купить план на какое-то время. все.

G>1) users (id, name)
G>2) plans (id, name, days, price)
G>3) orders (userid, planid, date)
G>все.

не подойдет — см выше.

Здравствуйте, sin_cos, Вы писали:

_>что так сложно? какие контрагенты. план, у него есть кол-во дней и цена. смены плана нет. все.

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

Здравствуйте, sin_cos, Вы писали:

_>>>есть планы, есть пользователи, пользователь может купить план на какое-то время. все.

G>>1) users (id, name)
G>>2) plans (id, name, days, price)
G>>3) orders (userid, planid, date)
G>>все.

_>не подойдет — см выше.
Какую из одной описанной операции нельзя выразить в рамках этой схемы?