Ask A Question

Notifications

You’re not receiving notifications from this thread.

Need someone to look over this to make sure i am on the right track...

Alan Reid asked in General

So this site i am building goes something like this.

I need to let users log in and manage their brands, each brand belongs to a company. A company can have many users which manage this brand. The brand has many products associated with it. Now this is where things get complicated haha.

A company can have many brands, but also it could have many venues. (The venues sell the brand)

I guess what i am after is validation to make sure i am on the right path lol

Companies

  • has_many :users
  • has_many :brands
  • has_many :venues

Brands

  • belongs_to :companies
  • has_many :products

Venues

  • belongs_to :companies

Users

  • belongs_to :companies
Reply

I think you're on the right track Alan. Do Venues sell all the Brands of a company or just specific ones? You might want a relationship between those two as well.

Reply

Cheers Chris,
Its more about getting my head around how Rails does things haha :)

Venues will have the ability to sell all products within a brand so to expand on some other actions...

Companies, who are not brands can follow brands - think twitter. So i will set up that up in a separate table. -- on the companies table i think i will need a "flag" is_brand so i can tell which is a brand or not.
Venues will sell/stock products - i assume this would be a different table.

Drawing it on paper is easier than writing it how Rails deals with it. But in reality it so much easier than other languages I've worked with haha.

Cheers again Chris, all input is a massive help.

Reply

Ah, so Company and Brand are effectively the same thing. That's interesting to know. You might check out STI (Single Table Inheritance) for those. It lets you use the same table for two different types when they share pretty much all the same fields.

Venues makes sense as a different table. You'll probably want some more for Products as well.

Definitely draw it out on paper. I often will do that and it helps you figure out what types of things you can and can't do with your data structure that way.

Reply

ohhhh this is where it gets interesting.

Yes company and brand can be the same thing, however a company can have multiple brands haha and under those brand you could have 1 or many products in that brand line up.

Think Bacardi. Bacardi & Company Limited is the Company, Bacardi is the main brand the have for their Rum. However you also have Bacardi Breezers, which are a brand themselves.

See it can be quite confusing, which is why i thought i would make sure i was going the right way.

Reply

https://samurails.com/tutorial/single-table-inheritance-with-rails-4-part-1/ interesting article about STI. Will investigate this further

Reply

To update the first post...

Companies - has the is_brand flag

  • has_many :users
  • has_many :brands
  • has_many :venues

Brands

  • belongs_to :companies
  • has_many :products

Products
-belongs_to :brands

Venues

  • belongs_to :companies

Users -- This is using devise

  • belongs_to :companies
Reply

That makes sense. You may want to make Brand a separate table so it can have all its own fields separate from Company.

It feels separate logically, and probably would be safest to separate out instead of saving them both to the same table. It also helps make the relationship easier where a Company can have many Brands. If you did them as a single table, you'd have a lot of self-referential stuff going on and I'm not sure that'd be good.

The only downside to separating them is that sometimes you might have a Company that only has one Brand and it's basically the same details for both.

Reply

Cool thanks Chris, you've really helped - more than you know lol.

I am sure i will get more questions haha :D

Reply
Join the discussion
Create an account Log in

Want to stay up-to-date with Ruby on Rails?

Join 85,376+ developers who get early access to new tutorials, screencasts, articles, and more.

    We care about the protection of your data. Read our Privacy Policy.