How to keep tables uncluttered by using profiles for each user type in Ruby on Rails

This is a continuation of my STI / Single Table Inheritance article: “How to use multiple User types with the same model in Rails aka STI or Single Table Inheritance

To keep your tables less cluttered and better normalized, I do recommend creating profile tables for each user type. What I did is this for my student’s example:

I have a student_profiles table with things like skype_username, birthdate, etc. To set this up You’ll want to do your migration.

Then we edit the Student model like so:

Now you can keep your user table and class more minimal and separate everything out into their own model. I also recommend putting all of these folders in models/users folder. To do that though you will need to edit config/application.rb and add the following line:

Thinking ahead you may want to group more models together, especially if you have a large number of models and tables, to do that you’ll just need to add a new line the same thing as above, just change the last part of the path to match the path to the folder with your models, and you should be good to go!


How to Use Multiple User Types (STI or Single Table Inheritance) with the Same Model in Ruby on Rails

Lately, I’ve been building a complex CRM for music teachers to manage students, invoicing, etc… It’s gotten a bit complicated, and I myself have learned a lot from this side project. One important thing I’ve learned is STI, or Single Table Inheritance. Basically, this lets you easily have sub models with their own intricacies, relationships, etc so you don’t clog up the main user class, but they all use the same table, and are easier to modify on their own.

I have admin.rb, student.rb, parent.rb, and teacher.rb files with classes to go with them…

I’ve built this all using Sorcery for the backend, but you can use devise, or whatever else floats your boat.

The first step is creating a “type” attribute on the users table. This is required by STI to know which type of user we’re dealing with. I’m going to assume you already have your user authentication system all setup.

Next you’ll want to create a subclass. For this example we’re just going to use Student.

When we create this, we also need to make sure that when the “type” attribute is set it’s always titleized. You’ll get errors and have issues if for instance the user.type was set to “student” and not “Student”. Case matters in this case.




Now, just make sure each user has a type, or perhaps have some sort of fallback, or default type as well. Then whenever you query Student.all or Teacher.all you’ll be pulling data out of the users table, but only get back Student and Teachers.

Next you may want to checkout my article on: How to keep tables uncluttered by using profiles for each user type.

More good articles on Single Table Inheritance / STI: