I am designing a vocabulary quiz application in ruby/rails.
I have basic model/association setup which will work, but i am worried about scalability.
There will be a set number of words in the application. For simplicity, lets say 100.
A user will be able to proceed to a question, which will be generated from looking at which questions they have had before. The question will provide a word and 4 choices for the definition (one being the definition, three other definitions being randomly chosen).
Here is the way my models and associations are set up currently;
class User < ActiveRecord::Base
has_many :user_questions
end
class UserQuestion < ActiveRecord::Base
belongs_to :user
belongs_to :vocab_word
end
class VocabWord < ActiveRecord::base
has_many :user_question
end
Assuming i were to keep this basic model, which of the following approaches should i use?
Have a set number of UserQuestion objects (100) per user and use
calculated columns to store statistics the users performance on
particular words. (e.g. user 502 has attempted the word 'arid' 3
times and correctlty answered 2 times).
For each question
attempt, create a new UserQuestion object. (e.g. user 502 attempted
to guess 'arid' and was incorrect)
Are either of these approaches scalable? If the application had one million users, the first strategy would have 100 million rows in user_questions. the second could have much more than that.
You're almost there. I would recommend extending your model with the following, plus the slight correction on UserQuestion and User association.
class User < ActiveRecord::Base
has_and_belongs_to_many :user_questions
end
class UserQuestion < ActiveRecord::Base
has_and_belongs_to_many :users
belongs_to :vocab_word
end
class VocabWord < ActiveRecord::base
has_many :user_question
end
class Attempt < ActiveRecord::base
belongs_to :vocab_word
belongs_to :user
belongs_to :user_question
attr_accessible :result
end
You'd need a user_questions_users association table to have a many-to-many association between questions and users. I believe it would be scalable. Make sure you set your indexes correctly.
Related
So, after thinking on this for a while, I have no idea what the proper way to model this is.
I have a website focused on sharing images. In order to make the users happy, I want them to be able to subscribe to many different collections of images.
So far, there's two types of collections. One is a "creator" relationship, which defines people who worked on a specific image. That looks like this:
class Image < ActiveRecord::Base
has_many :creations
has_and_belongs_to_many :locations
has_many :creators, through: :creations
end
class Creator < ActiveRecord::Base
has_many :images, ->{uniq}, through: :creations
has_many :creations
belongs_to :user
end
class Creation < ActiveRecord::Base
belongs_to :image
belongs_to :creator
end
Users may also tag an image with a subjective tag, which is something not objectively present in the image. Typical subjective tags would include "funny" or "sad," that kind of stuff. That's implemented like this:
class SubjectiveTag < ActiveRecord::Base
# Has a "name" field. The reason why the names of tags are a first-class DB model
# is so we can display how many times a given image has been tagged with a specific tag
end
class SubjectiveCollection < ActiveRecord::Base
# Basically, "User X tagged image Y with tag Z"
belongs_to :subjective_tag
belongs_to :user
has_many :images, through: :subjective_collection_member
end
class SubjectiveCollectionMember < ActiveRecord::Base
belongs_to :subjective_collection
belongs_to :image
end
I want users to be able to subscribe to both Creators and SubjectiveTags, and to display all images in those collections, sequentially, on the home page when they log in.
What is the best way to do this? Should I have a bunch of different subscription types - for example, one called SubjectiveTagSubscription and one called CreatorSubscription? If I do go this route, what is the most efficient way to retrieve all images in each collection?
What you want to use is a Polymorphic Association.
In your case, it would look like this:
class Subscription < ActiveRecord::Base
belongs_to :user
belongs_to :subscribeable, polymorphic: true
end
The subscriptions table would need to include the following fields:
user_id (integer)
subscribeable_id (integer)
subscribeable_type (string)
This setup will allow a subscription to refer to an instance of any other model, as ActiveRecord will use the subscribeable_type field to record the class name of the thing being subscribed to.
To produce a list of images for the currently logged in user, you could do this:
Subscription.where(user_id: current_user.id).map do |subscription|
subscription.subscribeable.images.all
end.flatten
If the performance implications of the above approach are intolerable (one query per subscription), you could collapse your two types of subscribeables into a single table via STI (which doesn't seem like a good idea here, as the two tables aren't very similar) or you could go back to your initial suggestion of having two different types of subscription models/tables, querying each one separately for subscriptions.
I'm building my first Rails project and it's a checkout system for a computer loaner pool. Creating Technicians (who perform checkouts) and CheckOuts (like transactions) makes perfect sense. However, I'm struggling with the relationship between CheckOuts and LoanerComputers.
Technician and CheckOut have a 1:N relationship, and CheckOut and LoanerComputerhave a 1:1 relationship. I believe in my Rails-n00b heart that it would be nice to have association proxy, e.g. Technician.check_outs.loaner_computers or even better Technician.loaner_computers, but from what I've learned that would mean that my LoanerComputer class must contain the belongs_to, and that assumes that the LoanerComputer table in my database has a check_out_id column.
I've tried thinking about it from a "rental" approach, but I see lots of solutions that have a fourth model to store state changes of the thing being "rented." To me, it makes more sense to have technician_id and loaner_computer_id in a single CheckOut entry, but then how could I easily access a technician's checked-out loaner computers using association proxy? Is it possible to use :delegate in this instance, or does it look like I'd have to make a custom method to read loaner computers via technicians? Here's example code:
class Technician < ActiveRecord::Base
has_many :check_outs
end
class CheckOut < ActiveRecord::Base
belongs_to :technician
# has_one :loaner_computer
# OR
# belongs_to :loaner_computer (which means I need to have a "loaner_id" column in the db, right?)
end
class LoanerComputer < ActiveRecord::Base
# belongs_to :check_out (which means I need to have a "check_out_id" column in the db)
# OR
# has_one :check_out
end
P.S. Do I just have it all backwards? Should I say Technicians has_many LoanerComputers, and LoanerComputers has_many CheckOuts?
Thanks for your time! Let me know if anything needs clarification!
I think, what you're looking for - is "has_many through" association.
http://guides.rubyonrails.org/association_basics.html#the-has-many-through-association
In Your case - It'll look like this
class Technician < ActiveRecord::Base
has_many :check_outs
has_many :loaners, through: :check_outs
end
class CheckOut < ActiveRecord::Base
# Must have technician_id and check_out_id fields in DB
belongs_to :technician
belongs_to :check_out
end
class Loaner < ActiveRecord::Base
has_many :technicians, through: :check_outs
end
With this - You'll be able to access loaners from technician and reverse
Technician.loaners
Loaner.technicians
You can also access check_outs from both models
I'm wracking my brain about how to start setting up the following set of model relationships in my project. I'm not looking for the complete solution (models, tables, migrations, etc), just a little help to get me going in the right direction. I learn more by struggling on my own :)
In short, I want my Users (created with Devise) to have a set of Inclinations that represent preferences they have to certain things (i.e. warmer weather vs colder weather, watching sports vs playing sports, etc) on a sliding scale (coded 5 to -5, zero excluded). Each Inclination (or InclinationData?) will be in a separate table with a name, description, etc, and all Inclinations will get their data pulled from that table (so I don't repeat myself throughout my application). Also, every User will have one Inclination record for each InclinationData(?) by default.
As for the setup, will I need:
5 tables (3 main ones and two join tables)?
Just three (main three models)?
Four (main three models & a joining table for Inclinations and InclinationData)?
Four (main three models & a joining table for Users & Inclinations)?
Perhaps something simpler like a single Profile or Preferences model that's bound to a User?
I can never figure out how to decide if joining tables are necessary, and this is the most complex association I've ever tried.
I appreciate any help, and please let me know if you need more information to be able to help me out.
You say, all Users have the same set of Inclinations. You can put the description of the Inclinations in one model/table and the users ratings in the joining table UserInclination , according to eabraham:
class User < ActiveRecord::Base
has_many :users_inclinations
has_many :inclinations, through: :users_inclinations
end
class UsersInclination < ActiveRecord::Base
belongs_to :users
belongs_to :inclinations
attr_accessible :user_id, :inclination_id, preference_score
end
class Inclination < ActiveRecord::Base
has_many :users_inclinations
attr_accessible :description, :name, :low_label, :high_label
end
So you can pull the description (i.e. to build the rating form) from Inclinations and store the individual ratings with
an_inclination= Inclination.find_by_name('weather')
user.user_inclination.create(inclination: an_inclination, preference_score: the_users_score)
I think I've reasoned through your request:
Users has_many UserInclinations and Inclinations has_one UserInclinations. Roughly, the models should look like this:
class User < ActiveRecord::Base
has_many :user_inclinations
#default Devise attr_accessible
end
class UserInclinations < ActiveRecord::Base
belongs_to :users
belongs_to :inclinations
attr_accessible :user_id, :inclination_id, preference_score
end
class Inclination < ActiveRecord::Base
has_one :user_inclination
attr_accessible :preference
end
I am relatively new to ruby/rails and I have the following question:
I am working on a scheduling app and have a model named Classes and another named ClassEntries. The relationship between them is that each user can have multiple class entries per semester, each relating to one class. Each record in the Classes table belongs to a specific University. A User can have multiple entries in the ClassEntries table for 1 semester (typically 5). Their schedule is comprised of all their ClassEntries with the same semester ID.
I am not sure whether I should have a third model called Schedule that brings together the info in the ClassEntries and Classes models for the user at hand. I originally wrote this functionality in PHP and I simply used a MySQL JOIN to gather the necessary information. In Rails it seems that there should be a better way to accomplish this.
What would be the best way of going about this in Rails?
Many thanks
So, what you are looking for is pretty much associations in Rails.
You would have the following:
def User < ActiveRecord::Base
has_many :course_entries
has_many :courses, :through => :class_entries
end
def CourseEntry < ActiveRecord::Base
belongs_to :user
belongs_to :course
end
def Course < ActiveRecord::Base
has_many :course_entries
has_many :users, :through => :class_entries
end
With those associations set up, Rails would allow you to do such things like
some_user.courses or some_course.users and it will make the joins through CourseEntry for you.
Let me know if this helps. If you need me to go more in depth let me know.
So I have the following models in my Ruby on Rails setup: users and courses
The courses need to have content_managers and those content_managers are made up of several individuals in the users model.
I'm a newbie, so bear with me. I was thinking of creating a new model called content_managers that has a user_id and a course_id that links the two tables. It makes sense to me that courses HAVE content_managers. However from the users model, it doesn't make sense that users HAVE content_managers. Some of them ARE content_managers.
From that point of view I believe I'm thinking about it incorrectly and need to set up my ActiveRecord in a different manner from what I'm envisioning. Any help is appreciated.
Thanks!
There's no "have" or "are" in ActiveRecord, only "has_many", "has_one" and "belongs_to". With those tools you should be able to do what you want.
An example:
class Course < ActiveRecord::Base
has_many :content_managers
end
class ContentManager < ActiveRecord::Base
has_many :content_manager_members
has_many :users,
:through => :content_manager_members,
:source => :user
end
class ContentManagerMember < ActiveRecord::Base
belongs_to :course_manager
belongs_to :user
end
class User < ActiveRecord::Base
has_many :content_manager_members
has_many :content_managers,
:through => :content_manager_members
end
Be sure to index these correctly and you should be fine, though navigating from User to Course will be slow. You may need to cache some of this in order to find the level of performance you want, but that's a separate issue that will be uncovered during testing.
Whenever implementing something like this, be sure to load it up with a sufficient amount of test data that will represent about 10x the anticipated usage level to know where the ceiling is. Some structures perform very well only at trivial dataset sizes, but melt down when exposed to real-world conditions.