Re: Database structure confusion

I'm writing an app right now that also requires a large form (for student applications).

Here is my plan for it and why:

- Basic user information first so that saving and returning later will work; this would have it's own user model used for authentication and authorization around the site - I have three different roles in mine: student, teacher, and staff. Each role would have it's own model to store extended user info since there is different info required for each (we don't need the transcripts for staff for example). - The extended user info would be in each role's model. I looked at the fedena source code and this is what they do. (Fedena is a student management system written with rails 2.something, so if you look at it and you're using rails 3.x, some things might be a bit different.) They have basic user info in one model and extended info in a separate model, but that's as far as they split it up. - I'm using multi-step forms to help with user experience. There's a railscast for that using javascript: http://railscasts.com/episodes/217-multistep-forms

However, my usage may be different than yours. If you are going to have separate views for a user's projects and have different actions and stuff pertaining to those projects, then yes, projects should be a separate model. The same goes for any of the other categories. But if you are just listing the info as it pertains to a single user, it would be fine to keep it in one model I think (I'm not sure about the performance impact of that though).

Last edited by gorrillamcd (2012-03-26 14:08:23)

Change is a vector. You can have all the change in the world, but if it doesn't go in the right direction, what good is it? | techonamission.com