Topic: Early Design Issue: keeping data separated or making multiple apps?

hello, everyone,

my situation is similar to dylanfm's as posted here:
A noob's desire to get it "right" the first timebut my question is about a different part of the site design.

We are just getting started with a new Rails app and we want to map it out in pretty good detail before we get going.

Our site is basically a online exam application where we will have 'semester's' and each semester will have its own set of questions, users, answers, etc.
There will be very little carry over between semesters, except the questions will be copied over.

The question I have is what would be the 'rails way' to divide these semesters up? 
At first I was thinking of using a simple table/object for semester where each semester would have_many questions, users, answers ...
But because each semester is essentially its own entity, it seems like a bad idea to keep all the data from every semester in one big database.
Rather, it makes more sense to me currently to have each 'semester' basically be their own rails app, with their own database - keeping everything separated in that way.
Is this a good idea?

The admins of the site would have to be easily able to create a new semester, and if it was done as new rails applications, that would mean my over-all app would have to be able to generate new apps easily... which I haven't been able to glean much info of how that would be done.

So what is a better way to do this?

In my mind, the situation seems similar to how shopify.com operates: a user can go on and create their own 'site'. Each site has all the set-up to add/manage products, collections, etc, but the data between sites is never shared.
Would this be done by making the whole site a plugin?
i'm missing something important here

Thanks very much for any help
Jim V

Last edited by vlandham (2007-02-16 14:22:05)

Re: Early Design Issue: keeping data separated or making multiple apps?

Unless there is a requirement for data to NOT be shared, then I would probably go to having a single app/database for the multiple semester.  I run a large application (PHP-based) where I took the separate app model and have regretted ever since.  Am working on rewriting it into Rails and keeping it combined now.

The main problem is that you end up with a ton of little things that want to be shared -- users, permissions, possibly announcements, etc.  Perhaps later you want to add some analytic tools for exploring which questions are asked most often or least often, etc  at which point it'll be much easier if its all in one place.

My RoR journey  -- thoughts on learning RoR and lessons learned in applying TDD and agile practices.

Re: Early Design Issue: keeping data separated or making multiple apps?

Good point, thanks for your response.

I guess I was thinking about how the users / admins would reach the tests, and thought it would be easiest if they could do something like this:

www.domain.com/fall_06/admin/

where fall_06 is a semester.
This page would bring up admin functionality on data for that semester.

But I'm thinking that we could do this with routes without much problem,
And if we had to, we could always use a before_filter to limit the data.

Thanks again
Jim

Re: Early Design Issue: keeping data separated or making multiple apps?

Definitely go with one rails app. I don't think you will get any benefit dividing it up into many rails apps/databases, and it will just cause a lot of complications. You can give each semester their own URL through routes. You can even do a subdomain:

fall_06.domain.com/admin

See this wiki article for details on the subject.

Railscasts - Free Ruby on Rails Screencasts

Re: Early Design Issue: keeping data separated or making multiple apps?

My current project has a similar situation. We are developing a hosted application that will have data from all of our customers but each customer can only access their own data.

We have kept the data seperate by tagging each table with an organization_id. So a user belongs to an organization and each piece of data belongs to an organization and only when they match can a user see the data.

There are some places where there isn't a need for this seperation, for example all organizations use the same data-glossary and shared-global configuration settings (set by us and not the customers).

Re: Early Design Issue: keeping data separated or making multiple apps?

Thanks for the suggestions.
I like the subdomain idea a lot,
and I think tagging could be useful for certain portions of our application.

We'll keep it as one Rails app.

Back to the design - we'll see where I get stuck next!


Thanks again,
Jim