I have been struggling for the past few hours thinking about which route I should go. I have a Notification model. Up until now I have used a notification_type column to manage the types but I think it will be better to create separate classes for the types of notifications as they behave differently.

Right now, there are 3 ways notifications can get sent out: SMS, Twitter, Email

Seems like STI is a good candidate right? Of course Twitter/SMS won't have a subject and Twitter won't have a sent_people_count, valediction. I would say in this case they share most of their fields. However what if I add a "reply_to" field for twitter and a boolean for DM?

My point here is that right now STI makes sense but is this a case where I may be kicking myself in the future for not just starting with MTI?

To further complicate things, I want a Newsletter model which is sort of a notification but the difference is that it won't use event_id or deliver_by.

I could see all subclasses of notification using about 2/3 of the notification base class fields. Is STI a no-brainer, or should I use MTI?

Where you use single table inheritance for your core notification fields. Then offload all the unique items to specific tables/models in a belongs to/has one relationship with your notification subclasses.

It's a little more overhead to set up, but works out to be pretty DRY, once all the classes and tables are defined. Seems like a pretty efficient way to store things. With eager loading you shouldn't be causing too much additional strain on the database.

For the purposes of this example, lets assume that Emails have no unique details. Here's how it maps out.

Each of the detail tables will contain a notification ID and only columns that form of communication needs that isn't included in the notifications table. Although it would mean an extra method call to get media specific information.

This is great to know but do you think it's necessary?

Very few things are necessary in terms of design. As CPU and storage space drop in cost so do those necessary design concepts. I proposed this scheme because it provides the best of both STI and MTI, and removes a few of their weaknesses.

As far as advantages go:

This scheme provides the consistency of STI. With tables that do not need to be recreated.
The linked table gets around dozens of columns in that are empty in 75% of your rows. You also get the easy subclass creation. Where you only need to create a matching Details table if your new type isn't completely covered by the basic notification fields. It also keeps iterating over all Notifications simple.

From MTI, you get the storage savings and the ease of customization in meeting a class's needs without needing to redefine the same columns for each new notification type. Only the unique ones.

However this scheme also carries over the major flaw with STI. The table is going to replace 4. Which can start causing slowdown once it gets huge.

The short answer is, no this approach is not necessary. I see it as the most DRY way to handle the problem efficiently. In the very short run STI is the way to do it. In the very long run MTI is the way to go, but we're talking about the point where you hit millions of notifications. This approach is some nice middle ground that is easily extensible.

As an added bonus, you can now access (read, write, relate) the subclass-specific attributes directly: notification.phone_number, without resorting to: notification.details.phone_number. You can also write all code in the main classes and subclasses, leaving the Details model empty. You will also be able to do less queries (in the above example 4 instead of N+1) on large datasets using Notification.all_with_details instead of the regular Notification.all.

Be aware, that at the current time this gem isn't tested very well, though it works in my usecase.

This is great to know but do you think it's necessary?
–
TonyOct 28 '09 at 15:31

I've added my answer to this question to my answer as there's not enough room in a comment box. The short version is: No. But that doesn't mean it's a flawed solution.
–
EmFiOct 28 '09 at 17:58

Thanks for the great explanation. I haven't found any articles online about implementing mixed model. Do I just need to create a notifications table and then a details table for each type of detail? I wish I could vote you up more for the excellent response. And one last quick question. You say in the very long run MTI is the way to go...well then why not just set that up to begin with? Do you say this because the extra details call will eventually lead to bad performance? I guess speed/DRY tradeoff.
–
TonyOct 28 '09 at 18:18

1

I tried this implementation but the notification_id is not getting passed through to the details model
–
DamianOct 29 '09 at 12:07

1

Of course it isn't. I guess I was a little unclear there. Unless you declare :foreign_key => :notification_id in the belongs to statement in a detail model, then rails assumes the notification_id column is named after the association named in the belongs_to relationship. Ie: :belongs_to :twitter is looking for a twitter_id column, not a notification_id column.
–
EmFiOct 29 '09 at 16:52

I know this is old, but after having come up with a solution I see potential answers which could use it everywhere! I recently forked a promising project to implement multiple table inheritance and class inheritance in Rails. I have spent a few days subjecting it to rapid development, fixes, commenting and documentation and have re-released it as CITIER Class Inheritance and Table Inheritance Embeddings for Rails.

I think it should allow you to do what you needed by simply constructing the models where Twitter, Email and SMS inherit from Notification. Then have the migration for Notifications only include common attributes, and the ones for the three subtypes include their unique attributes.

Or even define a function in the root Notification class and overload it in subclasses to return something different.