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 http://railscasts.com/episodes/221-subdomains-in-rails-3

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