For instance, let’s say I have a User model. Users have things like logins, passwords, e-mail addresses, avatars, etc. But there are two types of Users that will be using this site, let’s say Parents and Businesses. I need to store some different information for the Parents (e.g. childrens’ names, domestic partner, salaries, etc.) than for the Businesses (e.g. industry, number of employees, etc.), but also some of it is the same, like logins and passwords.
How do I correctly structure this in a SQL-based database? Thanks!
–UPDATE–
After digging a little bit more, I’m thinking that a polymorphic association might actually make more sense. But I don’t know a lot about them, is there a reason why I wouldn’t want to use them, or that STI is better? It seems like they’re exactly the same except that the fields specific to Parents or Businesses are stored in separate tables, which I think is what I would want. Isn’t it?
In an object-oriented environment this would be modeled through inheritance. There are several ways to map inheritance into database tables. The most simple is Single Table Inheritance. If you have an object oriented environment consuming the database this is worth looking into.
Update: STI vs. other alternatives
If the number of fields that differ is small, I would go for STI as this is simple to implement and doesn’t add the need for extra joins. The two other main alternatives are
Table per Class
If there are a lot of fields that are different between the types it is preferrable. The downside is that nearly all queries will require join operations betwen the base class table and one or more sub class tables.
Table per Concrete Class
To remedy the join problem of Table per Class a Table per Concrete Class is another way. However it requires common fields belonging to an abstract base class to be present in several tables. This violates the DRY principle and requires union queries to get the common properties from several concrete types.