# Designing a user system: Groups or STI? **URL:** \ **Category:** Rails\ **Created:** [July 18, 2008, 5:23pm UTC](https://www.ruby-forum.com/t/designing-a-user-system-groups-or-sti/143445 "2008-07-18T17:23:43Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![mhfs](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b2d939/32.png) [@mhfs](https://www.ruby-forum.com/u/mhfs)\ **Post date:** [July 18, 2008, 5:23pm UTC](https://www.ruby-forum.com/t/designing-a-user-system-groups-or-sti/143445/1 "2008-07-18T17:23:43Z")
Hello list, 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: - Clients - Photographers - Suppliers - Member 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! Thanks, Marcelo. ---
**Author:** ![mhfs](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b2d939/32.png) [@mhfs](https://www.ruby-forum.com/u/mhfs)\ **Post date:** [July 20, 2008, 9:11pm UTC](https://www.ruby-forum.com/t/designing-a-user-system-groups-or-sti/143445/2 "2008-07-20T21:11:29Z")
No one ever stumbled upon this design issue? On Fri, Jul 18, 2008 at 12:23 PM, Marcelo de Moraes S. \< ---
**Author:** ![mhfs](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b2d939/32.png) [@mhfs](https://www.ruby-forum.com/u/mhfs)\ **Post date:** [July 21, 2008, 8:14am UTC](https://www.ruby-forum.com/t/designing-a-user-system-groups-or-sti/143445/3 "2008-07-21T08:14:06Z")
This is just a thought, but you might be trying to do too much with STI. If Groups work well for authorization, then use Groups for authorization. (btw, this approach sounds a lot like RBAC where a Group is like a “role” in RBAC) If STI works well for (whatever), use STI for that. This means that you will have to keep the two in sync, but you should also get the benefits of both as well. ---
**Author:** ![mhfs](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b2d939/32.png) [@mhfs](https://www.ruby-forum.com/u/mhfs)\ **Post date:** [July 24, 2008, 7:00pm UTC](https://www.ruby-forum.com/t/designing-a-user-system-groups-or-sti/143445/4 "2008-07-24T19:00:52Z")
Thanks Eric, Yes, I was talking about RBAC, I just didn’t know the term at the time 🙂 Actually I think I can reformulate my original question as: “Is using STI to create subtypes of Users for access control a good practice/pattern?” I’ve been asking this question in #rubyonrails, and found out that most people don’t use STI in the User model for access control. I think it could work for small applications, but bigger applications need something that can be managed at runtime, i.e: roles of users can be changed at runtime. With STI, your “roles” (subclasses of the User model class) aren’t made for being switched at runtime. Of course, you can change the type attribute, but that is awkward at its best, and creating new “roles” involves creating new classes at the filesystem. STI works well for other more static elements, but for access control, hmm, I don’t think so. I don’t think a User model should have subclasses. Thanks, Marcelo. On Mon, Jul 21, 2008 at 3:14 AM, Erik R. \<