Geek Answers Handbook

Implemented Rails Basecamp Style Subdomains

My goal is to have separate user accounts for each subdomain. Under no circumstances do I want cross-pollination between subdomains.

I looked through Robby Russle and DHH thoughts (both are pre-Rails3, though).

Controlling the controller is pretty straight forward, my questions are about storing model data. What is the best way to save user1 from viewing user2 data?

Some ideas may include:

  • Add subdomain_id foreign key for each model. Advantage. A simple one-to-many relationship can be used to cover each model with a subdomain. - The disadvantage is a rather tight connection between the data and the larger application logic, which seems inappropriate.

  • One-to-many :through for each model that associates it with a subdomain - Advantage, you do not need to add a subdomain_id foreign key column to existing tables that associate them with their subdomain. - The disadvantage, my gut feeling is that this is the way of the excess. Several attachment requests may become more complex and cross-pollination errors may occur.

  • Separate applications or databases for each subdomain - Benefit, data is completely separated. - The disadvantage should be management / update / protection / deployment, etc. A large number of individual applications / databases.

  • Your idea

+7
source share
2 answers

Option 5. Guy Naor scheme solution - Advantage. It just blew my mind. Mostly transparent to rails, FULL data sharing, only one database, works great for applications that were not originally designed as multi-user. amazing - The disadvantage is that you need to use Postgres or some other database that supports schemas (I still use PG), you will need to iterate over the existing schemas during migration.

Right now, this seems like a distant and better way. Are there any serious flaws?

+7
source

If you are sure that the relationship between objects and subdomains will always be individual, I would choose option 1. If objects can be associated with several subdomains in the future, you are tied to option 2. This carries more overhead, but is easily managed by using something something like cancan.

I would stay away from option 3 for the reasons you mentioned. Rails doesn’t have many databases running, and in addition, using multiple databases in one application does not guarantee more security than other options.

+1
source

More articles:


All Articles