I have a “best practices” question. I have an app with several aggregate models that belong to one another. For example, a “Survey” (with many questions, answers, etc.) belongs to a “User” (with contacts, etc.).
As I originally wrote it, it was a simple “belongs_to user” on the survey model. Now though, I realized I want to have surveys that belong to entire groups, not just users. I could go back and add an association on Survey, but it makes me wonder…
Since there’s nothing intrinsic to the Survey attribute that has anything to do with User, should I have made it a many-to-many association using a join table simply for the purpose of decoupling the aggregates, even though there will never be more than one user per survey? This seems to have several benefits – I can modify/add/delete associations without mucking with the Survey table in the database, and I create the survey aggregate before creating its associations.
It sounds like you may want to have a Group table which users belong_to, or are associated with if they can be in multiple groups. The survey model could be a polymorphic association with either a user or group. The polymorphic association will give you a bit of flexibility in modeling in my opinion.
A join table is great if the join contains information that you need which is independent of the user or survey.
Thanks for the suggestions. I do indeed have a groups table to which Users belong.
Polymorphism is an interesting idea, but I need some Surveys to simultaneously belong to a User and a Group. (The User may belong to the group, but may possibly also belong to a subgroup…)
Maybe it isn’t such a big deal to put user_id and group_id attributes directly on Survey. It bugs me because they will be null for a bunch of surveys, and the Survey code is kind of separate from the fact that they happened to be owned by a complex set of Users and Groups in this particular application. I was thinking if I could separate out the associations into separate tables, it might keep Survey cleaner. However, there is no extra info I need to put in the join table, so I’m not sure that it buys me anything.
I would avoid putting user_id and group_id on Survey, if its at all possible that a Survey would be taken by two or more users. You could do two join tables, one for the survey to user, and one for survey to group. You will need to have some model methods to check if its a user survey vs group survey depending on how you plan on using it.
Even if you do not have join table specific attributes you would probably benefit from a many-to-many. I just have a personal preference of a join table because you could always think of some metadata to add to an association, if not now then maybe in the future.
Sweet! I’ll do that then. I just wanted to make sure there wasn’t a downside to using a join table if (at the moment) I only have at most one user and one group per Survey. But who knows–that could change!
Jess