The mongoid documentation told me that n-n relations should be used with caution
I understand his but don't have an idea how to solve my problem a better way using pure mongoid:
A course has many participants and a participant could participate with many courses. So wouldn't it be faster to store the participant on the course model and do a search over all courses when all courses of a participant are needed?
Your model should be reflective of your use cases.
One way to do this would be to have one model for the courses, one for participants and a 3rd that maps students to courses (with a unique index on course & student to prevent duplicates). This way there is a single model referring to the other 2. This may or may not be ideal based on your access patterns.
I think this is probably a good use case for embedding documents. See the sample syntax on the front page for embeds_many and embedded_in: http://mongoid.org/en/mongoid/
The main downside here is that if you have participants in more than one course, you will have duplicate participants in each of those courses.
Make sure you put an index on the fields you plan to do your lookups for participants with.
Related
I wasn't able to put well into words (in Question title) what I'm trying to do, so in honor of the saying that an image is worth a thousand words; In a nutshell what I'm trying to do is..
Basically, what I have is A Teacher has many Appointments and A Student has many Appointments which roughly translates to:
I'm trying to stay away from using the has_and_belongs_to_many macro, because my appointments model has some meaning(operations), for instance it has a Boolean field: confirmed.
So, I was thinking about using the has_many :through macro, and perhaps using an "Appointable" join table model? What do you guys think?
The Scenario I'm trying to code is simple;
A Student requests an Appointment with a Teacher at certain Date/Time
If Teacher is available (and wants to give lesson at that Date/Time), She confirms the Appointment.
I hope you can tell me how would you approach this problem? Is my assumption of using the has_many :through macro correct?
Thank you!
Both teachers and students could inherit from a single class e.g. Person. Then create an association between Person and Appointments. This way you keep the architecture open so that if in the future you want to add 'Parents' then they could easily be integrated and may participate in appointments.
It may not be completely straightforward how you do the joins with the children classes (Students, Parents, Teachers). It may involve polymorphic relationships which I don't particularly like. You should though get away with a single join table.
In any case, you want to design so that your system can be extended. Some extra work early on will save you a lot of work later.
Hopefully we have good rails developer who can definitely give correct answer! For 2 days I didn't receive any valid answer for my question
I will explain in a very simple example
Customer is offering product. When he pushes create it gives form. Choose a category. Once he chooses another form will pop up.
Depending on a category, form should have totally different attributes.I can't have Product.new for every category. Reason is they have different attributes(Logicaly true). So do I have to create 100 models for 100 categories
Categories are : cars, apartments, coupons, books and many more
If you can give just one example I will be gratefull and call you expert
Thanks
It sounds like you're getting there. However, I wouldn't have a bunch of models like you're indicating in your question. I would say that you need a Product model and a Category model. The Category model will belong_to Product. The Product model would have many Categories. The Category model can use the acts_as_tree gem so that you can have categories and subcategories. Use javascript or jQuery (there was a recent Railscasts on this) to dynamically change and post a different field with a set of choices based on what was chosen.
EDIT:
I would have three Models; Product, Category, Specification
Product has many Categories
Product has many Specifications through Categories
Category belongs to Product
Category has many Specifications
Specification belongs to Category
This way I can create a product that has several categories. I can create several categories that have several specifications. Specifications are linked to the respective category. This will allow you to have three models and limited number of classes. Once your project is complete, new categories and specifications can be maintained by a web admin instead of a programmer.
This isn't the answer you want, but you're going to need a lot of models.
The attributes associated with an apartment (square meters, utilities, floor of building) are completely different from the attributes associated with a car (make, model, mileage, condition) which are completely different from a book (title, author, publisher, edition, etc). These items are so fundamentally different that there is no way to manage them in a single model.
That being said, there may be a core collection of attributes that might be associated with a product that is for sale (seller, price, terms). You have basically two paths forward:
You could decide to use Single Table Inheritance. In this case, you'd create an abstract class that defines the attributes that are common to all products that you are selling (seller, price, item). You'd then add a "type" column to your database that would be used to determine what type of product it is (mapped to your categories), and define all of the possible attributes in a single table.
You could choose a core set of attributes, and use these as a part of any other object that is considered a product. You'd have multiple tables that would have the full record for any given object.
Without knowing a lot of details about your application, it's hard to make a specific recommendation about which approach is right for you. Your best bet at this point is to spend a lot of time on google with "single table inheritance rails" and "multi table inheritance rails" and figure out which one is right for you (though my gut says multi table).
Sorry the title is pretty unclear - I'm just not quiet sure how to phrase the question without explaining it.
I would like to record workouts with my app. I would like a Workout Table (what I'm calling the parent) that has basic information like date and sub_workout_type_id
A workout record can have either a Cardiovascular workout (One Model) or a Strength Workout (Another Model).
My thought on have 3 tables instead of just the 2 Cario Workout model and strength workout model is that I would be able to pull a feed of any type of workout, by pulling the Workout Records and then dig deeper as needed.
Perhaps there is a more ruby-ish way to do this? Because right now I don't know of a way to say has_one_model_or_the_other. Thanks!
I see two options, either you use STI (single table inheritance) : in that case you would have a single table that would be able to contain both a cardiovascular model or a strength workout, and a type. This would only work if the two models share some common characteristics.
Another solution is to write something like
has_one :cardiovascular
has_one :strength
and then use validations to enforce that only one of them is set.
Hope this helps.
As mentioned by #nathanvda, STI could be a good choice.
If you're looking to store class specific data with your models, maybe check out Modeling inheritance with Ruby/Rails ORMs to see if that answer gives you any ideas on how to model this relationship.
Note, the example there uses has_many's but a lot of the ideas are similar.
I have a Model of Key Termsthat can belong to many Articles (1 Term can be used in many articles)? so a user can add key terms used and their explanations to articles for which they are used in? what would be the best way to establish this relationship?
Thank You
You'll want to use a many-to-many relationship so you'll need to use has_and_belongs_to_many (see here). And you'll need to create an interim table for key_term_id and article_id columns named key_terms_articles to maintain the connection.
I think what you want is what's referred to as a HABTM (has and belongs to many) relationship. There's a lot of stuff out there on the topic, and it can be a bit confusing at first to grasp. Try searching for "activerecord HABTM" or "Activerecord polymorph" and that should get you started.
Say you have a Book model that can belong to multiple categories. Categories are predefined, but we might let the user add his own even though most of the time default ones are enough.
What is the best way to deal with that according to you ?
a) a many to many relationship to a Category model ? But isn't that overkill given the fact default categories are enough most of the time ?
b) booleans for each default category and an extra string for user entered categories
C) just a string and the use of serialize ? But then it might be a bit more tricky to use checkbox inputs for the default choices
d) any other suggestion of yours...
Thanks for your time!
Thanks
You'll probably want to use HABTM. It's not overkill if you're ever going to want to collect any sort of information about the various categories; date created, for example. You'll also gain the ability to easily fetch all books for a given category without having to worry about scopes inside the book model.
Also, down the road you might want to be able to add other objects to categories. There's not much overhead, and it's quite simple to set up, so worth going for, IMHO.
For help on implementing HABTM with checkboxes, check out the HABTM Checkboxes railscast. For a discussion of the differences between HABTM and has_many :through, I really recommend the Two Many-to-Many railscasts.