Henry Happ wrote: > > A more concrete example would be, say, that for a school, a contact can > be an inquiry, an applicant, a student, a teacher, a mentor, etc. In > this scenario, a person could be a student and a mentor at the same > time. Data is collected for applicants and when they are approved, they > become a student (their application data is retained). A student has > other specific information to be collected and can be linked to other > data in the system. > > TIA.
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. -- 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 -~----------~----~----~----~------~----~------~--~---
