Multi-Companies oriented application - HOW ?

Hi, I'm looking to developing an application which is multi-companies oriented application - something like basecamp (but different business area), where many companies can use that web based application. Any Idea what would be the best way to hold information for each company - so that every company works as if it was their website ? Thank you in advance for any suggestion, Dani

Dani Dani wrote in post #960711:

Hi, I'm looking to developing an application which is multi-companies oriented application - something like basecamp (but different business area), where many companies can use that web based application. Any Idea what would be the best way to hold information for each company - so that every company works as if it was their website ?

Associate each record with a company.

Thank you in advance for any suggestion, Dani

Best,

I guess the best way is to use subdomains for each company: company1.yourdomain.com, company2.yourdomain.com, etc. It will be easier for users to perceive. You can learn how to work with subdomains in Rails 3 here #221 Subdomains in Rails 3 - RailsCasts

Good luck,

Marnen Laibow-Koser wrote in post #960765:

Associate each record with a company.

Thank you Marnen. So it means each record should have an extra field to associate a record with a certain company. I had this also in mind, but I thought there are other better ways than this.

Any more Ideas ? Dani

Marnen Laibow-Koser wrote in post #960765:

Associate each record with a company.

Thank you Marnen. So it means each record should have an extra field to

associate a record with a certain company. I had this also in mind, but

I thought there are other better ways than this.

Any more Ideas ?

Marnen’s advice is the easiest and most usual way - create a Company model and then associate to it as needed. So the question you would have to answer is why not do it this way? There are apps which might create a new db for each company/client. There are sometimes reasons to do so, but I would not want to do this without a very good reason. That would be a second possible way.

Marnen Laibow-Koser wrote in post #960765:

Associate each record with a company.

Thank you Marnen. So it means each record should have an extra field to associate a record with a certain company. I had this also in mind, but I thought there are other better ways than this.

Any more Ideas ?

That's really the only sane way of doing things. If you're thinking about modeling data in a database hot-dogging without putting your data into a normal-form should be done with a really, really good reason (and most times not even then).

Cheers, Brian

Marnen Laibow-Koser wrote in post #960765:

Associate each record with a company.

Thank you Marnen. So it means each record should have an extra field to

associate a record with a certain company. I had this also in mind, but

I thought there are other better ways than this.

Any more Ideas ?

That’s really the only sane way of doing things. If you’re thinking

about modeling data in a database hot-dogging without putting your

data into a normal-form should be done with a really, really good

reason (and most times not even then).

Not that I have experience with this, but I guess going the non-relational route you would not have to ‘associate’ data the way we think of it but in the end you still are doing it logically… again, something to be done for good reasons as there would be costs and benefits to this route.

> Marnen Laibow-Koser wrote in post #960765: >> >> Associate each record with a company. >> >>> > Thank you Marnen. So it means each record should have an extra field to > associate a record with a certain company. I had this also in mind, but > I thought there are other better ways than this. > > Any more Ideas ?

That's really the only sane way of doing things. If you're thinking about modeling data in a database hot-dogging without putting your data into a normal-form should be done with a really, really good reason (and most times not even then).

Not that I have experience with this, but I guess going the non-relational route you would not have to 'associate' data the way we think of it but in the end you still are doing it logically.... again, something to be done for good reasons as there would be costs and benefits to this route.

Oh, sure. One great reason for going the non-relational route is high volume traffic on your data store. Updating and reading all those pretty referential links does incur overhead, which some products can ill afford to pay. Folks using Redis often end up building some of the referential data that they need by hand. More possibility for bugs[1], but, if you take care and _know_ certain properties of your data will never need to be queried, better performance in some cases.

Normal form by default with plans to strip away NF criteria as needed is good rule of thumb. Rather reminds me of the carpenter adage: "It is easier to cut than to add some on."

1. DataMapper takes this pain away.

Wow, great, thank you.

So to summarize, I'll have to create a table holding "companies", then each record in each table should have a "company_id" pointing to the associated company in the companies table ?

By the way Brian, what do you mean by NF in the "strip away NF criteria..." sentance ?.

Regards, Dani

Wow, great, thank you.

So to summarize, I'll have to create a table holding "companies", then each record in each table should have a "company_id" pointing to the associated company in the companies table ?

Yep.

By the way Brian, what do you mean by NF in the "strip away NF criteria..." sentance ?.

Oh, sorry: NF is an initialization of Normal Form.

Dani Dani wrote in post #960786:

Wow, great, thank you.

So to summarize, I'll have to create a table holding "companies", then each record in each table should have a "company_id" pointing to the associated company in the companies table ?

Well, not necessarily in each table. For example, suppose you have a system where documents belong to users, and users belong to companies. You need a company_id on the users table, but you don't need one on the documents table, because the company_id can be deduced from the user_id (by looking to see which company the user belongs to).

By the way Brian, what do you mean by NF in the "strip away NF criteria..." sentance ?.

Regards, Dani

At this point, I would strongly advise you to read about relational database design and normalization. The Wikipedia articles on DB normalization are excellent.

Best,

You may not need to associate everything to the company of course. For example, if the company has products and each product has drawings then you would use Company has_many products Product belongs_to company Product has_many drawings Drawing belongs_to product So Product has a company_id field to tie it to a company and Drawing has a product_id field to tie it to a product. There is therefore no need to associate the drawing to the company as this is already implied by the other associations.

Have a look at the Rails Guide on ActiveRecord Associations if this is new stuff for you.

Colin

Thank you all for your support. Have a nice weekend.

Dani