This is more of a architectural question and I hope someone out there could enlighten me.
I’m starting the object model of my current project, and I can see that there will be various kinds of users, such as:
I would usually just add the semantic and categorization using a n:n relationship with a Group entity. However, I also detected that some of these “user kinds” might have additional attributes and business logic tied to them. For example, a Photographer will have a field of “cameras” that could even be a has_many relationship with a Camera entity. This could not be done with a Group alone.
I can see that both approaches, Group and STI allow you to:
- Categorize and control permission.
- Identify a user semantically in code and perform code depending on the “kind/group” of the user.
But STI is has some advantages if you want additional attributes and logic tied to the subtype model.
Group is nice to manage permissions and they can be changed, created and assigned to a user at runtime, something STI can’t do since it requires a ruby class in the filesystem.
I’m kind of confused on how I solve this issue, if someone has some tip or design principles to help me here, I would be really grateful!