Ar Chron wrote: > My $0.02: > > I'd say that you have one main "generic" model (Person), and several > other models that are related to a person, but not quite instances of a > person such as STI would imply, as a person could be multiple things at > once. > > Each of these other related models has their own set of unique > information (prospect information, application data, standardized test > scores, current schedule, academic records, teaching schedule, etc) that > shouldn't be mashed together, to say nothing of the temporal nature of > being a student, or a teacher, or a mentor (you could be some of these > things at the same time, or repeated over distinct instances of time). > > But everyone has a name, one or more addresses, emails, phones, etc that > would be an attribute of a person (from the application point of view). > Common attributes go in the generic person, domain specific (student, > teacher, applicant, prospect) attributes go in a related table linked to > the Person.
You have absolutely captured what I was trying to say and have restated the needs much more clearly than I did. If it's not too bold to ask, could you please explain in a more concrete way how to implement the structure describe in Rails? -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
