my data is currently structured in the following way.
STATE (ie California) "has_many" SCHOOLS,
SCHOOL "has_many" GRADES (ie 8th grade or 9th grade),
GRADE "has_many" CLASSES (ie art, history, chemistry),
CLASSES "has_many" STUDENTS.
My goal is to get low-level detail from a high-level view, otherwise, I would like to get all students (lowest denominator within the data structure) within the STATE (highest level component within the structure). What's the easiest and most efficient way to structure this so I can have a command to get all students within a state, ie "State.find(name: "California").students".
I tried a two level "through" association but it seems to be limited.
A potential basic data design would be something like the following:
class State < ActiveRecord::Base
has_many :schools
has_many :students, through: :schools
end
# Links students to schools
class Enrollment < ActiveRecord::Base
belongs_to :school
belongs_to :student
belongs_to :grade
end
class School < ActiveRecord::Base
has_many :enrollments
has_many :students, through: :enrollments
has_many :grades
has_many :subjects, through: :grades
belongs_to :state
end
# Denotes a educational step as in 1st grade
class Grade
belongs_to :school
has_many :subjects
end
# We can't use Class since it clashes with the Class object.
class Subject
belongs_to :grade
end
class Student < ActiveRecord::Base
has_many :enrollments
has_many :schools, through: :enrollments
end
State.find(1).students would join through School and Enrollment.
Flattening the structure would require a states_students join table which is pretty unsexy due to data duplication. The duplication means more slow insert and update queries when creating / updating students. The same applies to subjects and grades.
This does not address differentiating between current and former students which could be solved by adding an end date or a enum denoting the status to Enrollment.
Enougher issue is dealing with data that might be shared by all Grades or Classes. Like for example goals that would be setup on a state level and not on a school level. Another case is a subject which might stretch though several grades.
Related
I have four interrelated models: restaurants, menus, sections, and dishes. The dishes have_and_belong_to_many sections and ultimately are at the very bottom of the association chain. In my app I often need to reference the restaurant of the dish multiple times.
I know to accomplish this I'd need create a cascade of HMT associations. My question is, is it ideal to setup a belongs_to relationship between a restaurant and dish to avoid the multiple queries or leave as is? As of now this just feels dirty (may just be me though).
class Restaurant < ApplicationRecord
has_many :menus, dependent: :destroy
has_many :dishes, through: :menus
end
class Menu < ApplicationRecord
has_many :sections, dependent: :destroy
has_many :dishes, through: :sections
belongs_to :restaurant
end
class Section < ApplicationRecord
belongs_to :menu
has_and_belongs_to_many :dishes
end
class Dish < ApplicationRecord
has_and_belongs_to_many :sections
end
The denormalization you propose here seems reasonable to me given your use case. As always, the performance gains of denormalization must be weighed against the complexity it introduces, especially the need to write code to ensure that a the restaurant a dish belongs to is always the same restaurant its section's menu belongs to.
I guess my approach would be: Retain the normalized data model until you have an actual performance problem that needs to be addressed. Then you can consider denormalizing to address it.
While you are still have the cascade of HMTs, consider writing delegators to make the code as clean as if you had a direct restaurant-dish association. I'm thinking:
class Dish < ApplicationRecord
delegate :restaurant, to: :section
end
class Section < ApplicationRecord
delegate :restaurant, to: :menu
end
Then you can do:
dish.restaurant
I have to perform a complex active record query.
I have 5 models
Card Model
class Card < ActiveRecord::Base
has_many :leads
has_many :programs, through: :leads
end
Leads Model
class Lead < ActiveRecord::Base
belongs_to :card
belongs_to :program
end
Program Model
class Program < ActiveRecord::Base
has_many :leads
has_many :cards, through: :leads
belongs_to :school
end
School Model
class School < ActiveRecord::Base
has_many :programs
belongs_to :representative
end
Representative Model
class Representative < ActiveRecord::Base
has_many :schools
end
I want to count the number of cards each school and each representative has. A representative has many schools, a school has many programs, and a program has many cards.
I know I have to perform an inner join but after some research I haven't found any precise instructions. Thank you for your help.
Adding a few more associations to some of your models should help a bit.
class School < ActiveRecord::Base
# in addition to existing relations
has_many :leads, through: :programs
has_many :cards, through: :leads
end
class Representative < ActiveRecord::Base
# in addition to existing relations
has_many :programs, through: :schools
has_many :leads, through: :programs
has_many :cards, through: :leads
end
Then, the simple way to get the number of cards that a single school or representative has should be simple.
#school.cards.count
#representative.cards.count
If you'd to get the number of unique cards, i.e. a card could be associated to multiple programs within the same school or representative and you'd like to count each one only once, then use distinct.
#school.cards.distinct.count
#representative.cards.distinct.count
Now, if you're looking to get the number of cards that each school and representative has, that's a bit trickier, but still possible.
#schools = School.select('schools.*, count(cards.id)')
.joins(programs: { leads: :card } )
.group(:id)
#reps = Representative.select('representative.*, count(cards.id)')
.joins(schools: { programs: { leads: :card } } )
.group(:id)
If you'd like the unique number of cards for each school or representative, just change count(cards.id) to count(distinct cards.id) in the appropriate query.
A few notes about these solutions:
If a school or representative has zero cards, they will not appear in in the #schools and #representatives variables. In order to make them appear, you'll need to adjust the query a bit and use LEFT JOIN.
You probably don't even really need the association to :cards in the School and Representative models to get the counts; you could probably just use the :leads association. However, this would make getting distinct a bit more difficult, so that's why I went with :cards.
I'm a little confused on which type of association I should set up in my application.
I have these three models: Booking, Availability and Facility
A facility puts up 1 hour blocks of available time. So I'd say Availability: belongs_to :facility.
I'm trying to represent that a booking could have many availabilities. In that if I book from 1-3PM that's two 1 hour blocks and I'd like for that to be represented in 1 record in the Bookings table.
I was thinking I should set up Bookings: has_many :availability
but then I was reading about has_many though and I wasn't sure if it would be more appropriate to do Facilities has many Bookings through Availability...?
I would absolutely do a has_many :through association here, but I'd make the association between Availability and Booking slightly different than a typical has_many :through association:
class Facility < ActiveRecord::Base
has_many :availabilities
has_many :bookings, through: :availabilities
end
class Availability < ActiveRecord::Base
belongs_to :facility
has_one :booking
end
class Booking < ActiveRecord::Base
belongs_to :availability
end
The reason I prefer this association style is because in a typical has_many :through, you have two entities sharing relationships with one another through a third entity (e.g. Patients and Doctors sharing a relationship through an entity called Appointment, as explained by the Rails guides). This example is different, however, in that Booking shouldn't hold any positive relationship to Facility--the relationship should merely be a by-product of an open Availability.
I would like to create a double entry table form according two models.
For now I'm able to create a simple table with the members of a communities
on the columns, I must add the informations of an other model, like this :
My models :
Community
has_many :memberships
Membership
belongs_to :user
belongs_to :community
User
has_many ::memberships
has_many :skills
Skill
belongs_to :user
belongs_to :community
I there some gem existing to make a double entry table or is it easier to make it from scratch? if so, how can I begin ?
It seems like you would benefit from a through relationship here.
Instead of referencing community directly from the skill table, you could do:
Skill
belongs_to :user
has_many :communities, :through => :user
On user, add:
has_many :communities, :through => :memberships
Wouldn't this get the link between skill and community that you would like?
As Jay mentioned, you would benefit from a has_many :through relationship, or maybe a has_and_belongs_to_many relationship; whether it's the actual solution we'll have to see:
#app/models/user.rb
Class user < ActiveRecord::Base
has_many :memberships
has_many :skill_users
has_many :skills, through: :skill_users
end
#app/models/skill_user.rb
Class SkillUser < ActiveRecord::Base
belongs_to :skill
belongs_to :user
end
#app/models/skill.rb
Class Skill < ActiveRecord::Base
has_many :skill_users
has_many :users, through: :skill_users
end
This will allow you to associate each user (note that members are different than users) with specific skills without using double-entries in your tables
Relational
The basis of what you're seeking can be found in Relational Databases
These work by storing data in single instances, and linking to other data through foreign_keys. These foreign keys are things such as user_id etc:
(more information here)
This means instead of populating the same data twice, it is correct to reference that data from other models, as required. This is where join models come in
Join Model
Join models allow you to "link" two pieces of data through a join model:
For you, it means storing your skills in its own model, and linking users with skills on a join model (I've called skill_user.rb). This means that you'll be able to call your user's skills like this:
#user.skills #-> goes through the join model
I'm in the process of trying to develop my first rails application and before I jump off into actually implementing my ideas, I was hoping I could get some help with my association planning.
My application is going to be an educational tool and I have some basic functionality that I need to implement. I want to have students that can register for and create courses. Within these courses, there will be one user who is the teacher and the rest are students. Within the course will be assignments that the teacher creates and that users are required to make a submission for. These are the basics. Eventually I want to add more functionality but as of now I just need the foundations set.
Here are my ideas so far on what the associations should look like:
class User < ActiveRecord::Base
has_many :enrollments
has_many :courses, :through => :enrollments
end
class Course < ActiveRecord::Base
has_many :enrollments
has_many :users, :through => :enrollments
end
class Enrollment < ActiveRecord::Base
belongs_to :user # foreign key - user_id
belongs_to :course # foreign key - course_id
end
However, I'm running into my wall of inexperience at the moment with how to appropriately handle the rest of the associations at this point. I could probably hack out something, but I'd prefer to do it as best as I can the first time.
How do I handle the associations related to assignments and submissions? Presumably a student's submission should belong_to them, but it is also specifically related to an assignment within the class. Assignments originate within a course, but are also closely tied to the user.
Finally, what's the best way to handle the relationships between a user and the class they create? A user creates a course. Does that course belong_to them? Should I just add a column to the course's table for storing the creator's id? Etc.
Thanks for the help.
Suggestion:
You might want to separate out your Teacher and Student models, since you're very likely to have different actions associated with each (and while they share some attributes, they really are different entities in your model, for example, you likely want just one teacher teaching in a course.)
You could derive both the Teacher model and the Student model from a User model that has the shared attributes and authentication.
Now to your questions:
If you'd like to keep the student that created the course associated, creator_id is the way I'd go. (If a teacher can create a course too, deriving Student and Teacher from a shared User model would help)
Assignments and Submissions:
You've pretty much defined it in words. Here is the code.
[If different students within a course could get different assignments, only then do you want to build a direct association between Student and Assignment, otherwise, use a through association]
class User < ActiveRecord::Base
has_many :enrollments
has_many :courses, :through => :enrollments
has_many :assignments, :through => :courses
has_many :submissions
end
class Course < ActiveRecord::Base
has_many :enrollments
has_many :users, :through => :enrollments
has_many :assignments
end
class Enrollment < ActiveRecord::Base
belongs_to :user # foreign key - user_id
belongs_to :course # foreign key - course_id
end
class Assignment < ActiveRecord::Base
belongs_to :course
has_many :submissions
end
class Submission < ActiveRecord::Base
belongs_to :assignment
belongs_to :user
end