用例(类似于Wix订阅模型)
用户可以拥有多个网站。为了拥有一个网站,他需要购买和维护订阅。
因此,如果他想要更多网站,他需要为他创建的每个网站购买并维护单独的订阅。
我正在为Rails设计一个数据库,我很困惑设计应该如何。
哪一个更好?
Client
has_many :websites
has_many :subscriptions, through: :websites
Website
belongs_to :client
belongs_to :subscription
Subscription
has_many :websites
belongs_to :client
has_many :pricing_plans
PricingPlan
belongs_to :subscription
或
Client
has_many :websites
has_many :subscriptions, through: :websites
Website
belongs_to :client
has_one :subscription
Subscription
belongs_to :website
belongs_to :client
has_many :pricing_plans
PricingPlan
belongs_to :subscription
还是有更好的设计?我还应该注意什么?如果用户取消订阅,则必须自动停用网站。
答案 0 :(得分:2)
在我看来,我会选择这样的事情:
Client
has_many :subscriptions
has_many :websites, through: :subscriptions
Subscription
belongs_to :client
has_one :website
has_one :pricing_plan_subscription
has_one :pricing_plan, through: :pricing_plan_subscription
Website
belongs_to :subscription
has_one :client, through: :subscription
PricingPlan
PricingPlanSubscription
belongs_to: :subscription
has_one: :pricing_plan
客户通过这些订阅会有许多订阅和许多网站。由于客户无法拥有没有订阅的网站,因此没有理由在第一个示例中将其反转。
此外,此解决方案的另一个关键区别是PricingPlan
和PricingPlanSubscription
与仅PricingPlan
。这样做的原因是您希望能够标准化定价计划并使其可以重复用于不同的用户。因此,“容器”PricingPlanSubscription
将允许您将定价计划与用户相关联,并在需要时更新计划。
要处理“停用”,我不会销毁订阅或网站,只需添加一列即可存档。这样,如果需要,您将来可以恢复它们。当然,您必须编写方法来处理此操作。