Posts [ 7 ]

Topic: Single Table Inheritance

Hello,

My application will have three different user types with user type Admin containing a dozen more table attributes than the other two. I am considering creating a basic user table with the fields username and password. With single table inheritance on this table, can I create a one-to-one relationship with the sub class for the Admin user to a table that can store additional user data? If so, would this be a sensible design?

Re: Single Table Inheritance

Single Table Inheritance is designed to work with just one table, so I think it would be better to create a separate Admin model and do a one-to-one relationship between that and user. You can place an admin_id column in the users table (or visa versa) and only fill it when the user is an admin. It's not as convenient as having it all in the same model, but it's the best way I know of.

Re: Single Table Inheritance

I've run into this several times before and I've found that, more often than not, I needed my super-big user model to be broken into two models. I usually have several types of users (including admins) all of which have to log into the site. Then, I have a Profile (or Contact) model that allows one of those users to have many other pieces of data associated with them.

One of my projects ran into a wall when I realized that several different user types needed totally unique (and really complicated) profiles associated with them. I was faced with separating an ever-growing users table into users, athlete_profiles, coach_profiles, school_profiles, etc. In the end I had a nice little 5-column users table that did it's job really nicely.

So, really the question is: what other kind of data does this Admin need?

Currently I have an Affiliate model which splits into Organisation and Journalist (single table inheritance). The general user has been forgotten about up until now. I'm rather pleased with the extended class setup for Affiliates, but now realise that something has to change if I'm going to get the General User into the user table.

Danger and RyanB, are you suggesting then that I throw away my single table inheritance model, and create a single table with the basic admin details (username and password) for all three user types, and create an additional profile table for organisations and journalists?

Re: Single Table Inheritance

I don't fully understand your situation so it is a little difficult to make a suggestion. How does the General User (is that a complete model or STI subclass?) fit in to the rest of the relationship? Are you currently using it?

If you already have a STI setup that is working well, I would stick with it. From my understanding you have several different kinds of users and any given one of them could become an admin? And the admin has many extra fields? I would create just one admin table with just the extra fields that is required for an admin - you don't need to repeat the username/password columns. You can then create an admin_id column in any table to link it to the Admin model.

The downside to this is you will need go through a second model in order to fetch the admin's information, but I can't tell if there is a better solution without a more complete understanding of the problem.

Re: Single Table Inheritance

My application has 3 users types (A, B and C). A and B can create content for the site and will have their own site within a site at user-nic.some-domain.com. The only difference between A and B is that A is an organisation, whereas B is a single user (journalist). Both A and B have a profile and some contact information. I would like for A and B to each have there own class, that is why I thought STI would work well here.

User C is just a regular site browser, who will be able to browse content and add comments. Users A and B will never change their type.

I suspect, from what you have said, that a suitable design would involve a single user table with an additional table for profiles for user a and b, with a profile id in the user table. Does that sound about right?

Re: Single Table Inheritance

camilo wrote:

I suspect, from what you have said, that a suitable design would involve a single user table with an additional table for profiles for user a and b, with a profile id in the user table. Does that sound about right?

It's hard to say what the best approach would be, but a separate profiles table would probably work well.