On 6/13/07, Matthew Jacobs
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:>
> When setting up my model, do I want to do all of my generate models at
> the beginning and then fill in the migrations/model scripts all
> referencing each other at the same time? Or should I start with just
> one model at a time and build in the dependencies later? I''m kind
of
> confused.
It doesn''t matter technically. But the general idea (as you can see
from the book) is to build the application in iterations, not trying
to model too far ahead. Things tend to change as you get into it. But
it helps to think about the "big picture", which is what
you''re trying
to do here.
> I want to model the situation where a teacher can add meeting
> notes/grades for a student who belongs to a given class in a given year.
> I think I''ll need the following tables:
>
> Years
> Classes (belongs to a year)
> Students (belongs to a class)
> Meetings (belongs to a student)
>
> The reason that years is a table is that some students take the class
> for several years (3-yr program) and we should be able to select one
> particular class from any given year.
I think you might need more models. For example, you might have a Year
and a Class (probably should change that to "Course", since
"class" is
a Ruby keyword). Example:
Year = 2007-08 academic year
Course = Basket Weaving
There''s probably a many-to-many relationship between those; any given
year can have many courses, and any given course could be offered in
multiple years. So you would use another model to represent that. What
would you call it? I don''t know what to call it, so I''ll call
it
"Offering"
So:
Year --> has_many --> Offering
Course --> has_many --> Offering
Now you have Student. This would information about a given student.
Now look at the relation between Student and Offerings. Any given
student could be enrolled in multiple offerings, and any given
offering would have multiple students. Again, you would use another
model to represent the relationship (because it''s many to many).
Let''s
call it Enrollment.
So:
Offering --> has_many --> Enrollment
Student --> has_many --> Enrollment
Where would a Meeting go? I think it would belong to Enrollment. If a
meeting represents a given student meeting with the teacher of a
specific course for a specific term, then Enrollment represents that.
So:
Enrollment --> has_many --> Meeting
Just some ideas. Worth what you paid for them :~)
--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---