The part of the database I am designing is to complete the following requirement: A user can signup for a business's subscription service. Each business predefines a set of tiers(levels) for their business. So business A might define 5 tiers while business b has only 2. When a user signs up for a subscription, they will choose which tier they want to purchase. A user can only have one subscription and tier for any given business, but a user can signup for multiple subscriptions of different businesses. A subscription must have an associated business and tier. The business will need to run reports to see how many subscriptions they have sold and when upcoming subscriptions are about to need renewing.

The entities I have are business, user, business_tier, subscription.

USER(user_id, user_attribute1...) BUSINESS(business_id, business_attr1...) BUSINESS_TIER(business_tier_id, business_id, tier_description) SUBSCRIPTION(subscription_id,business_id, user_id,tier_id, sub_start_date, sub_renew_date)

business to subscription is one to many-- tier to subscription is one to many-- user to subscription is one to many.

I think that's it.
Does this seem like the correct or best relational design?

  • "Best" is a quality that cannot be measured and its evaluation is relative to situation and perspective. Does it work for you? You have your requirements - can you satisfy all of those given the schema you propose? If you want someone to evaluate your schema, it is best to post it as DDL and not abbreviated pseudo-code. I'm certain you can find at least ONE attribute more descriptive than "attribute1" for user and business.
    – SMor
    Jul 30 at 12:16


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.